COLA分层架构
COLA 4.0 架构分成COLA架构和COLA组件两个部分：
- COLA架构：关注应用架构的定义和构建，提升应用质量。
- COLA组件：提供应用开发所需要的可复用组件，提升研发效率。
COLA架构：关注应用架构的定义和构建，提升应用质量。领域模型对设计能力要求很高，没把握用好，一个错误的抽象还不如不抽象，宁可不要用，也不要滥用，不要为了DDD而DDD。*
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 | 是 |
COLA 组件：提供了一些框架级别的功能，提供应用开发所需要的可复用组件，提升研发效率。
| 组件名称 | 功能 | 版本 | 依赖 |
|---|---|---|---|
| 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 | 无 |
参考：《 COLA 4.0：应用架构的最佳实践》
COLA框架职责划分
COLA框架主要分为适配层、应用层、Client模块、领域层、基础设施层
分层架构如下：
分包结构如下：
1）适配层（Adapter Layer）：负责对前端展示（web，wireless，wap）的路由和适配，对于传统B/S系统而言，adapter就相当于MVC中的controller；
2）应用层（Application Layer）：主要负责获取输入，组装上下文，参数校验，调用领域层做业务处理，如果需要的话，发送消息通知等。层次是开放的，应用层也可以绕过领域层，直接访问基础实施层；
3）Client模块（Client Module）：包含的代码应该是常见的服务接口Facade和DTO数据传输对象，如API、DTO、领域事件、Command和Query对象等等。
4）领域层（Domain Layer）：主要是封装了核心业务逻辑，并通过领域服务（Domain Service）和领域对象（Domain Entity）的方法对App层提供业务实体和业务逻辑计算。领域是应用的核心，不依赖任何其他层次；
5）基础实施层（Infrastructure Layer）：主要负责技术细节问题的处理，比如数据库的CRUD、搜索引擎、文件系统、分布式服务的RPC等。此外，领域防腐的重任也落在这里，外部依赖需要通过gateway的转义处理，才能被上面的App层和Domain层使用。
6）启动模块（Start Module）：Spring Boot的启动类，应用入口。没有任何逻辑，只需要配置 application.properties 配置文件。
CQRS架构模式
CQRS架构模式，在DDD中是一种很常见的模式，它的用途在于将Command与Query功能进行分离，让一些复杂的查询摆脱领域模型的限制，以更为简单的DTO形式展现查询结果。服务可以独立部署，也可以拆分部署。数据库可以使用一个，也可以读写分离。
在COLA 4.0中，已经移除了Command Bus和Query Bus的处理，进一步简化了COLA架构。
业务调用时序图
我们通过分三个场景的UML时序图描述一下各模块之间的调用关系。主要差异在于应用层中的Command或Query执行器的处理过程。
场景一：Command或Query执行器直接调用Gateway接口，处理业务请求。
场景二：Command或Query执行器，调用领域服务（Domain Service），然后领域服务调用Gateway完成业务请求。
场景三：Command或Query执行器直接调用infrastructure层中定义的Mapper，完成业务逻辑处理。
下面说明整体调用过程和注意事项。
Adapter接收Cmd/Qry对象或者参数列表（Request Param）。如果请求参数是参数列表，则构造Cmd/Qry对象，然后调用App Service接口。
App服务接收Cmd/Qry对象，然后调用Cmd/Qry Executor（执行器），如上图所示，分为以下三种场景：
2.1. Command Executor 可以通过领域实体方法，以及Gateway接口，实现简单业务编排，完成业务请求。
2.2. 或者通过调用领域服务（Domain Service）实现复杂业务逻辑处理，然后在领域服务通过Gateway访问数据的持久化。
2.3. 或者直接跳过Domain层，在Qry Executor中调用infrastructure中的Mapper接口，访问数据库持久化操作。App服务、Command Executor（命令执行器）以及Domain Serivce都是无状态服务，本身不存储任务信息。
App服务负责实现对外暴露的API服务，然后调用Command Executor.
Domain Service 负责封装一个领域中跨实体操作的业务逻辑。App Service 负责封装跨领域实体操作的业务逻辑。
Gateway接口用来隔离技术实现细节，GatewayImpl实现领域层定义的Gate接口，负责数据的CRUD操作，数据库测可以是MySQL、NoSql、Elasticsearch、Redis、甚至Hadoop/HBase等
分层架构、包结构、业务调用关系
下图将COLA分层架构、包结构、业务调用关系，整合在一张图中。
代码参考：《COLA 4.x架构入门和项目实践》
更多推荐
DDD（领域驱动设计）从入门到精通