开发笔记-02-cola4.0

2021-08-02

字数统计: 2.6k字 | 阅读时长≈ 9分钟

开发笔记-02-cola4.0

前言

COLA的主要目的是为应用架构提供一套简单的可以复制、可以理解、可以落地、可以控制复杂性的”指导和约束”。
同样，好的应用架构，也遵循一些共同模式，都提倡以业务为核心，解耦外部依赖，分离业务复杂度和技术复杂度。
应用架构的本质，就是要从繁杂的业务系统中提炼出共性，找到解决业务问题的最佳共同模式，为开发人员提供统一的认知，治理混乱。帮助应用系统“从混乱到有序”
COLA架构就是为此而生，其核心职责就是定义良好的应用结构，提供最佳实践。

开源项目地址： https://github.com/alibaba/COLA

1. Cola 分层架构

所有的复杂系统都会呈现出层级结构，应用系统处理复杂业务逻辑也应该是分层的，下层对上层屏蔽处理细节，每一层各司其职，分离关注点。
对于一个典型的业务应用系统来说，COLA会做如下层次定义，每一层都有明确的职责定义

适配层（Adapter Layer）：负责对前端展示（web，wireless，wap）的路由和适配，对于传统B/S系统而言，adapter就相当于MVC中的controller；
应用层（Application Layer）：主要负责获取输入，组装上下文，参数校验，调用领域层做业务处理，如果需要的话，发送消息通知等。层次是开放的，应用层也可以绕过领域层，直接访问基础实施层；
领域层（Domain Layer）：主要是封装了核心业务逻辑，并通过领域服务（Domain Service）和领域对象（Domain Entity）的方法对App层提供业务实体和业务逻辑计算。
- 领域是应用的核心，不依赖任何其他层次；
基础实施层（Infrastructure Layer）：主要负责技术细节问题的处理，比如数据库的CRUD、搜索引擎、文件系统、分布式服务的RPC等。此外，领域防腐的重任也落在这里，外部依赖需要通过gateway的转义处理，才能被上面的App层和Domain层使用。

2. Cola 包结构

分层是属于大粒度的职责划分，太粗，有必要往下再down一层，细化到包结构的粒度，才能更好的指导我们的工作。
还是拿一堆玩具举例子，分层类似于拿来了一个架子，分包类似于在每一层架子上又放置了多个收纳盒。所谓的内聚，就是把功能类似的玩具放在一个盒子里，这样可以让应用结构清晰，极大的降低系统的认知成本和维护成本。

那么，对于一个后端应用来说，应该需要哪些收纳盒呢？
- 基本上每一次COLA的迭代都会涉及到包结构的调整，迭代到现在，才算基本稳定下来。

各个包结构的简要功能描述，如下表所示：

层次	包名	功能	必选
Adapter层	web	处理页面请求的Controller	否
Adapter层	wireless	处理无线端的适配	否
Adapter层	wap	处理wap端的适配	否
App层	executor	处理request，包括command和query	是
App层	consumer	处理外部message	否
App层	scheduler	处理定时任务	否
Domain层	model	领域模型	否
Domain层	ability	领域能力，包括DomainService	否
Domain层	gateway	领域网关，解耦利器	是
Infra层	gatewayimpl	网关实现	是
Infra层	mapper	ibatis数据库映射	否
Infra层	config	配置信息	否
Client SDK	api	服务对外透出的API	是
Client SDK	dto	服务对外的DTO	是

为什么Domain的model是可选的？因为COLA是应用架构，不是DDD架构。
在工作中，领域模型要怎么设计，原则是：无有必要勿增实体。
领域模型对设计能力要求很高，没把握用好，一个错误的抽象还不如不抽象，宁可不要用，也不要滥用，不要为了DDD而DDD。
- 模型虽然可选，但DDD的思想是一定要去学习和贯彻的，特别是统一语言、边界上下文、防腐层的思想，值得深入学习，仔细体会。实际上，COLA里面的很多设计思想都来自于DDD。其中就包括领域包的设计。

为了兼顾领域维度的内聚性，有必要对包结构进行一下微调，即顶层包结构应该是按照领域划分，让领域内聚。
- 综合考虑功能和领域两个维度包结构定义。按照领域和功能两个维度分包策略，最后呈现出来的，是如下图所示的顶层包节点是领域名称，领域之下，再按功能划分包结构。

例如，在刚刚上线的一个云店铺（cloudstore）项目中，按照COLA的分包策略,在每一个module下面首先按照领域做一个顶层划分，然后在领域内，再按照功能进行分包。

3. Cola 解耦思想

“高内聚，低耦合” 这句话，工作的越久，就越会觉得其有道理。
所谓耦合就是联系的紧密程度，只要有依赖就会有耦合，不管是进程内的依赖，还是跨进程的RPC依赖，都会产生耦合。
- 依赖不可消除，同样，耦合也不可避免。我们所能做的不是消除耦合，而是把耦合降低到可以接受的程度。在软件设计中，有大量的设计模式，设计原则都是为了解耦这一目的。
在DDD中有一个很棒的解耦设计思想——防腐层（Anti-Corruption）
- 简单说，就是应用不要直接依赖外域的信息，要把外域的信息转换成自己领域上下文（Context）的实体再去使用，从而实现本域和外部依赖的解耦。
- 在COLA中，把防腐层这个概念进行了泛化，将数据库、搜索引擎等数据存储都列为外部依赖的范畴。利用依赖倒置，统一使用gateway来实现业务领域和外部依赖的解耦。
- DDD 带来最大的改变是让我们得以从“数据驱动”转向”领域驱动“，让我们知道领域是应用的核心，其他都是技术的细节，随时可以被替换。
其实现方式如下图所示，主要是在Domain层定义Gateway接口，然后在Infrastructure提供Gateway接口的实现。

举个例子：

假如有一个电商系统，对于下单这个操作，它需要联动订单服务、商品服务、库存服务、营销服务等多个系统才能完成。
- 那么在订单域，该如何获取商品和库存信息呢？最直接的方式，无外乎就是RPC调用商品和库存服务，拿到DTO直接使用就完了。
- 然而，商品域吐出的是一个大而全的DTO（可能包含几十个字段），而在下单这个阶段，订单所需要的可能只是其中几个字段而已。
- 更合适的做法，应该是在订单域中，使用gateway对商品域和库存域的依赖进行解耦。
这样做有两个好处，一个是降低了对外域信息依赖的耦合；另一个是通过上下文映射（Context mapping），确保本领域边界上下文（Bounded context）下领域知识的完整性，实现了统一语言（Ubiquitous language）。

4. Cola 组件

以上就是COLA架构的核心内容了。然而这么多module，这么多package，如果要手动去创建的话，是非常繁琐和费时的。为了能够快速创建满足COLA架构的应用，阿里有两个现成的cola Maven工程
- 一个是用来创建纯后端服务的archetype：cola-archetype-service
- 一个是用来创建adapter和后端服务一体的web应用archetype：cola-archetype-web
另外，也可以使用阿里云的应用生成器去生成一个COLA应用，只是那边的版本没有同步更新，可能会老旧一点。

COLA除了架构之外，还提供了一些框架级别的功能，比如拦截器功能，扩展点功能等。
- 可以单纯的使用COLA架构，而不使用任何COLA组件提供的功能也是完全没问题的。
为了方便管理，以及更清晰的把架构和框架区分开来。
- 在此次COLA 4.0的升级中，功能组件全部收拢到了cola-components下面。

组件名称	功能	版本	依赖
cola-component-dto	定义了DTO格式，包括分页	1.0.0	无
cola-component-exception	定义了异常格式，主要有BizException和SysException	1.0.0	无
cola-component-statemachine	状态机组件	1.0.0	无
cola-component-domain-starter	Spring托管的领域实体组件	1.0.0	无
cola-component-catchlog-starter	异常处理和日志组件	1.0.0	exception ,dto组件
cola-component-extension-starter	扩展点组件	1.0.0	无
cola-component-test-container	测试容器组件	1.0.0	无

5. 如何使用 cola

安装 cola archetype

下载cola-archetypes下的源码到本地，然后本地运行mvn install安装。

安装 cola components

下载cola-components下的源码到本地，然后本地运行mvn install安装。

3. 创建应用

mvn archetype:generate -DgroupId=com.alibaba.demo -DartifactId=demoWeb -Dversion=1.0.0-SNAPSHOT -Dpackage=com.alibaba.demo -DarchetypeArtifactId=cola-framework-archetype-web -DarchetypeGroupId=com.alibaba.cola -DarchetypeVersion=4.0.0

4.运行应用