关于阿里巴巴:如何保证同事的代码不会腐烂一文带你了解-Alibaba-COLA-架构

本文开始前，问大家一个问题，你感觉一份业务代码，尤其是互联网业务代码，都有哪些特点？

我能想到的有这几点：

• 互联网业务 迭代快 ，工期紧，导致 代码构造凌乱，简直没有代码正文和文档。
• 互联网 人员变动频繁 ，很容易接手他人的老我的项目， 新人基本没工夫吃透代码构造，紧迫的工期又只能让屎山越堆越大。
• 多人一起开发，每个人的编码习惯不同，工具类代码各用个的，业务命名也常常抵触，影响效率。
• 大部分团队简直 没有工夫做代码重构，任由代码腐烂。

每当咱们新启动一个代码仓库，都是信念满满，构造整洁。然而工夫越往后，代码就变得糜烂不堪，技术债权越来越宏大。

这种状况有解决方案吗？也是有的：

1. 小组内定期做代码重构，解决技术债权。
2. 组内设计欠缺的利用架构，让代码的腐烂来得慢一些。（当然很难做到齐全不腐烂）
3. 设计尽量简略，让不同层级的开发都能疾速看懂并上手开发，而不是在一堆简单的没人看懂的代码上堆更多的屎山。

而 COLA，咱们明天的配角，就是为了提供 一个可落地的业务代码构造标准，让你的代码腐烂的尽可能慢一些，让团队的开发效率尽可能快一些。

COLA 是什么

COLA 是由阿里大佬张建飞所提出的一种 业务代码架构的最佳实际，并且曾经在阿里云脚手架代码生成器中作为一个可选项，可见其曾经领有了肯定影响力。

COLA 是 Clean Object-Oriented and Layered Architecture 的缩写，代表“整洁面向对象分层架构”。

在 COLA 4.0，也就是目前最新的版本中，作者将 COLA 拆分为 COLA 架构（Archetype）和 COLA 组件（Components）两个局部：

• COLA 架构：COLA 利用的代码模板。
• COLA 组件：提供一些十分有用的通用组件，这些组件能够帮忙咱们晋升研发效率。

两者互不烦扰，能够独立应用。

COLA 整体架构

首先次要谈谈 COLA 架构，COLA 的官网博文中是这么介绍的：

在平时咱们的业务开发中，大部分的零碎都须要：

• 接管 request，响应 response；
• 做业务逻辑解决，像校验参数，状态流转，业务计算等等；
• 和内部零碎有联动，像数据库，微服务，搜索引擎等；

正是有这样的共性存在，才会有很多普适的架构思维呈现，比方分层架构、六边形架构、洋葱圈架构、整洁架构（Clean Architecture）、DDD 架构等等。

这些利用架构思维尽管很好，但咱们很多同学还是“不讲 Co 德，明确了很多情理，可还是过不好这毕生”。问题就在于不足实际和领导。COLA 的意义就在于，他不仅是思维，还提供了可落地的实际。应该是为数不多的利用架构层面的开源软件。

COLA 提供了一整套代码架构，拿来即用。 其中蕴含了很多架构设计思维，包含探讨度很高的畛域驱动设计 DDD 等。

留神：每个人对于架构设计都有着本人的了解。所以对于 COLA 的架构，本篇文章也仅仅只是我本人对于 COLA 的浅显了解，大家能够批评对待。

COLA 分层架构

先来看两张官网介绍图

其次，还有一个官网的表格，介绍了 COLA 中每个层的命名和含意：

这两张图和一个表格曾经把整个 COLA 架构的绝大部分内容展示给了大家，然而一下子这么多信息量可能很难消化。

既然整个示例架构我的项目是一个 Maven 父子构造，那咱们就从父模块一个个好好过一遍。

首先父模块的 pom.xml 蕴含了如下子模块：

<modules>
  <module>demo-web-client</module>
  <module>demo-web-adapter</module>
  <module>demo-web-app</module>
  <module>demo-web-domain</module>
  <module>demo-web-infrastructure</module>
  <module>start</module>
</modules>

start 层

该模块作为整个利用的启动模块（通常是一个 SpringBoot 利用），只承当启动我的项目和全局相干配置项的寄存职责。代码目录如下：

将启动独立进去，益处是清晰简洁，也能让新人一眼就看出如何运行我的项目，以及我的项目的一些根底依赖。

adapter 层

接下来咱们依照之前架构图从上到下的程序，一个个看。

首先是 demo-web-adapter 模块，这名字是不是很陈腐？但其实，能够了解为平时咱们用的 controller 层（对于 Web 利用来说），换汤不换药。

在 COLA 官网博客中，也能找到如下的形容：

Controller 这个名字次要是来自于 MVC，因为是 MVC，所以自带了 Web 利用的烙印。然而，随着 mobile 的衰亡，当初很少有利用仅仅只反对 Web 端，通常的标配是 Web，Mobile，WAP 三端都要反对。

cilent 层

有了咱们说的“controller”层，接下来有的小伙伴必定就会想，是不是 service 层啦。

是，也不是。

传统的 Web 利用中，齐全能够只有一个 service 层给 controller 层调用，然而作为一个业务利用，除非你真的只是个前端页面的有情吐数据机器，否则很大可能性你的利用会有很多其余上下游调用方，并且你须要提供接口给他们。

这时候你给他们的不应该是一个 Web 接口，应该是 RPC 调用的服务层接口，至于起因不是本文的重点，具体就不开展了。

所以在 COLA 中，你的 adapter 层，调用了 client 层，client 层中就是你服务接口的定义。

从上图中能够看到，client 包里有：

• api 文件夹：寄存服务接口定义
• dto 文件夹：寄存传输实体

留神，这里只是服务接口定义，而不是服务层的具体实现，所以在 adapter 层中，调用的其实是 client 层的接口：

@RestController
public class CustomerController {

    @Autowired
    private CustomerServiceI customerService;

    @GetMapping(value = "/customer")
    public MultiResponse<CustomerDTO> listCustomerByName(@RequestParam(required = false) String name){CustomerListByNameQry customerListByNameQry = new CustomerListByNameQry();
        customerListByNameQry.setName(name);
        return customerService.listByName(customerListByNameQry);
    }

}

而最终接口的具体实现逻辑放到了 app 层。

@Service
@CatchAndLog
public class CustomerServiceImpl implements CustomerServiceI {

    @Resource
    private CustomerListByNameQryExe customerListByNameQryExe;

    @Override
    public MultiResponse<CustomerDTO> listByName(CustomerListByNameQry customerListByNameQry) {return customerListByNameQryExe.execute(customerListByNameQry);
    }
}

app 层

接着下面说的，咱们的 app 模块作为服务的实现，寄存了各个业务的实现类，并且严格依照业务分包 ，这里划重点， 是先依照业务分包，再依照性能分包的，为何要这么做，文章前面还会多说两句，先看图：

customer 和 order 别离对应了生产着和订单两个业务子畛域。外面是 COLA 定义 app 层上面三种性能：

能够看到，音讯队列的消费者和定时工作，这类平时咱们业务开发常常会遇到的场景，也放在 app 层。

domain 层

接下来便是 domain，也就是畛域层，先看一下畛域层整体构造：

能够看到，首先是依照不同的畛域（customer 和 order）分包，外面则是三种次要的文件类型：

1. 畛域实体：实体模型能够是充血模型（请自行理解），例如官网示例里的 Customer.java 如下：

@Data
@Entity
public class Customer{

    private String customerId;
    private String memberId;
    private String globalId;
    private long registeredCapital;
    private String companyName;
    private SourceType sourceType;
    private CompanyType companyType;

    public Customer() {}

    public boolean isBigCompany() {return registeredCapital > 10000000; // 注册资金大于 1000 万的是大企业}

    public boolean isSME() {return registeredCapital > 10000 && registeredCapital < 1000000; // 注册资金大于 10 万小于 100 万的为中小企业}

    public void checkConfilict(){
        //Per different biz, the check policy could be different, if so, use ExtensionPoint
        if("ConflictCompanyName".equals(this.companyName)){throw new BizException(this.companyName+"has already existed, you can not add it");
        }

    }
}

2. 畛域能力：domainservice 文件夹下，是畛域对外裸露的服务能力，如上图中的 CreditChecker
3. 畛域网关：gateway 文件夹下的接口定义，这里的接口你能够粗略的了解成一种 SPI，也就是交给 infrastructure 层去实现的接口。

例如 CustomerGateway 里定义了接口 getByById，要求 infrastructure 的实现类必须定义如何通过消费者 Id 获取消费者实体信息，而 infrastructure 层能够实现任何数据源逻辑，比方，从 MySQL 获取，从 Redis 获取，还是从内部 API 获取等等。

public interface CustomerGateway {public Customer getByById(String customerId);
}

在示例代码的 CustomerGatewayImpl（位于 infrastructure 层）中，CustomerDO（数据库实体）通过 MyBatis 的查问，转换为了 Customer 畛域实体，进行返回。实现了依赖倒置。

@Component
public class CustomerGatewayImpl implements CustomerGateway {
    @Autowired
    private CustomerMapper customerMapper;

    public Customer getByById(String customerId){CustomerDO customerDO = customerMapper.getById(customerId);
      //Convert to Customer
      return null;
    }
}

infrastructure 层

最初是咱们的 infrastructure 也就是基础设施层，这层有咱们方才提到的 gatewayimpl 网关实现，也有 MyBatis 的 mapper 等数据源的映射和 config 配置文件。

所有层讲完了，COLA4.0 很简单明了，最初，在援用一段官网介绍博客原文来总结 COLA 的层级：

1）适配层（Adapter Layer）：负责对前端展现（web，wireless，wap）的路由和适配，对于传统 B / S 零碎而言，adapter 就相当于 MVC 中的 controller；

2）应用层（Application Layer）：次要负责获取输出，组装上下文，参数校验，调用畛域层做业务解决，如果需要的话，发送音讯告诉等。档次是凋谢的，应用层也能够绕过畛域层，间接拜访根底施行层；

3）畛域层（Domain Layer）：次要是封装了外围业务逻辑，并通过畛域服务（Domain Service）和畛域对象（Domain Entity）的办法对 App 层提供业务实体和业务逻辑计算。畛域是利用的外围，不依赖任何其余档次；

4）根底施行层（Infrastructure Layer）：次要负责技术细节问题的解决，比方数据库的 CRUD、搜索引擎、文件系统、分布式服务的 RPC 等。此外，畛域防腐的重任也落在这里，内部依赖须要通过 gateway 的本义解决，能力被下面的 App 层和 Domain 层应用。

COLA 架构的特色

说完了分层架构，咱们再来回顾下下面提到的 COLA 架构的几个特色的设计

畛域与性能的分包策略

也就是上面这张图的意思，先依照畛域分包，再依照性能分包，这样做的其中一点益处是能将腐烂管制在该业务域内。

比方消费者 customer 和订单 order 两个畛域是两个后端开发并行开发，两个人对于 dto，util 这些文件夹的命名习惯都不同，那么只会腐烂在各自的业务包上面，而不会将 dto,util,config 等文件夹放在一起，极容易引发文件抵触。

后面的包定义，都是性能维度的定义。为了兼顾畛域维度的内聚性，咱们有必要对包构造进行一下微调，即顶层包构造应该是依照畛域划分，让畛域内聚。

业务域和内部依赖解耦

后面提到的 domain 和 infrastructure 层的依赖倒置，是一个十分有用的设计，进一步解耦了取数逻辑的实现。

例如下图中，你的畛域实体是商品 item，通过 gateway 接口，你的商品的数据源能够是数据库，也能够是内部的服务 API。

如果是内部的商品服务，你通过 API 调用后，商品域吐出的是一个大而全的 DTO（可能蕴含几十个字段），而在下单这个阶段，订单所须要的可能只是其中几个字段而已。你拿到了内部畛域 DTO，转为本人畛域的 Item，只留下题目价格库存等必要的数据字段。

COLA 并不完满

诚然，COLA 曾经做的足够清晰简洁了，然而它依然有不完满的中央，比方每个接口的出入参都会依据业务名做定义，导致了很多构造极为类似的 DTO，DTO 的爆炸增长是个问题。参考：ISSUE-271

然而总的来说，COLA 只是给你提供了一种架构设计的思维，并不深刻到强制你应用某种标准的层面，所以对于 COLA 中你感觉简单，或者不了解的中央，很多时候须要你本人来做衡量，作取舍。取其精华，去其糟粕 的使用到你的我的项目中。

总结

COLA 架构并不简单，COLA 曾经从 1.0 版本通过逐次精简，倒退到了现在的状态。在阿里云代码脚手架生成器中作为一个可选项，足见其曾经趋于成熟。

下一篇文章，我会和大家一起探讨下 COLA 组件库中的一些重要组件，比方扩大点组件（cola-component-extension-starter），状态机组件（cola-component-statemachine）等。这些组件并不强制和 COLA 绑定，你齐全能够不应用这些组件，只应用 COLA 架构来设计你的利用。然而这些组件能够晋升团队的研发效率。

咱们下期再见，我是在阿里搬砖的工程师 蛮三刀酱

继续的更新原创优质文章，离不开你的点赞，转发和分享！

我的惟一技术公众号：后端技术漫谈

欢送加我集体号：BrodyYang

参考

COLA Github

https://github.com/alibaba/COLA

COLA 4.0.0 版本

https://blog.csdn.net/signifi…

COLA 3.1.0 版本

https://blog.csdn.net/signifi…

COLA 3.0.0 版本

https://blog.csdn.net/signifi…

COLA 2.0.0 版本

https://blog.csdn.net/signifi…

COLA 1.0.0 版本

https://blog.csdn.net/signifi…