资料
https://blog.csdn.net/significantfrank/article/details/110934799
源码
https://github.com/alibaba/COLA
背景
随着业务复杂性的逐步提高，为兼容各种场景，原有的代码也变得越来越复杂不易维护且容易出问题。故公司高层提出了重构我们现有的项目，经过几次会议的讨论，最终确定采用 COLA 架构作为本次重构的指导思想。
COLA 了解
分层结构
应用系统处理复杂业务逻辑也应该是分层的，下层对上层屏蔽处理细节，每一层各司其职，分离关注点，而不是一个 ServiceImpl 解决所有问题。对于一个典型的业务应用系统来说，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 层使用。
分包结构
分层是整体项目的职责划分，细分到包结构的粒度，才能更好指导我们的工作。
各个包结构的简要功能描述，如下表所示：
无有必要勿增实体。领域模型对设计能力要求很高，没把握用好，一个错误的抽象还不如不抽象，宁可不要用，也不要滥用，不要为了 DDD 而 DDD。
问题的关键是要看，新增的模型没有给你带来收益。比如有没有帮助系统解耦，有没有提升业务语义表达能力的提升，有没有提升系统的可维护性和可测性等等。
模型虽然可选，但 DDD 的思想是一定要去学习和贯彻的，特别是统一语言、边界上下文、防腐层的思想，值得深入学习，仔细体会。实际上，COLA 里面的很多设计思想都来自于 DDD。其中就包括领域包的设计。
前面的包定义，都是功能维度的定义。为了兼顾领域维度的内聚性，我们有必要对包结构进行一下微调，即顶层包结构应该是按照领域划分，让领域内聚。
也就是说，我们要综合考虑功能和领域两个维度包结构定义。按照领域和功能两个维度分包策略，最后呈现出来的，是如下图所示的顶层包节点是领域名称，领域之下，再按功能划分包结构。
解耦
实现 高内聚低耦合。
采用防腐层的解耦设计思想，不直接依赖外域的信息，要把外域的信息转换成自己领域上下文的实体再去使用，从而实现本域和外部依赖的解耦。
在 cola 中，将数据库、搜索引擎等数据存储也列为外部依赖的范畴。
其实现方式如下图所示，主要是在 Domain 层定义 Gateway 接口，然后在 Infrastructure 提供 Gateway 接口的实现。
举个例子，假如有一个电商系统，对于下单这个操作，它需要联动订单服务、商品服务、库存服务、营销服务等多个系统才能完成。
那么在订单域，该如何获取商品和库存信息呢？最直接的方式，无外乎就是 RPC 调用商品和库存服务，拿到 DTO 直接使用就完了。
然而，商品域吐出的是一个大而全的 DTO（可能包含几十个字段），而在下单这个阶段，订单所需要的可能只是其中几个字段而已。更合适的做法，应该是在订单域中，使用 gateway 对商品域和库存域的依赖进行解耦