COLA 4.0 - DDD项目实践

更多内容关注微信公众号：fullstack888

COLA分层架构

COLA 4.0 架构分成COLA架构和COLA组件两个部分：

1. COLA架构：关注应用架构的定义和构建，提升应用质量。

2. COLA组件：提供应用开发所需要的可复用组件，提升研发效率。

COLA 4.0 框架

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框架职责划分

COLA框架主要分为适配层、应用层、Client模块、领域层、基础设施层

分层架构如下：

COLA 4.0 分层架构

分包结构如下：

COLA 4.0 包结构模型

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

适配层代码结构

2）应用层（Application Layer）：主要负责获取输入，组装上下文，参数校验，调用领域层做业务处理，如果需要的话，发送消息通知等。层次是开放的，应用层也可以绕过领域层，直接访问基础实施层；

应用层代码结构

3）Client模块（Client Module）：包含的代码应该是常见的服务接口Facade和DTO数据传输对象，如API、DTO、领域事件、Command和Query对象等等。

Client模块

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形式展现查询结果。服务可以独立部署，也可以拆分部署。数据库可以使用一个，也可以读写分离。

CQRS架构

在COLA 4.0中，已经移除了Command Bus和Query Bus的处理，进一步简化了COLA架构。

业务调用时序图

我们通过分三个场景的UML时序图描述一下各模块之间的调用关系。主要差异在于应用层中的Command或Query执行器的处理过程。

场景一：Command或Query执行器直接调用Gateway接口，处理业务请求。

UML时序图：场景一

场景二：Command或Query执行器，调用领域服务（Domain Service），然后领域服务调用Gateway完成业务请求。

UML时序图：场景二

场景三：Command或Query执行器直接调用infrastructure层中定义的Mapper，完成业务逻辑处理。

UML时序图：场景三

下面说明整体调用过程和注意事项。

1. Adapter接收Cmd/Qry对象或者参数列表（Request Param）。如果请求参数是参数列表，则构造Cmd/Qry对象，然后调用App Service接口。

2. App服务接收Cmd/Qry对象，然后调用Cmd/Qry Executor（执行器），如上图所示，分为以下三种场景：
   2.1. Command Executor 可以通过领域实体方法，以及Gateway接口，实现简单业务编排，完成业务请求。
   2.2. 或者通过调用领域服务（Domain Service）实现复杂业务逻辑处理，然后在领域服务通过Gateway访问数据的持久化。
   2.3. 或者直接跳过Domain层，在Qry Executor中调用infrastructure中的Mapper接口，访问数据库持久化操作。

3. App服务、Command Executor（命令执行器）以及Domain Serivce都是无状态服务，本身不存储任务信息。

4. App服务负责实现对外暴露的API服务，然后调用Command Executor.

5. Domain Service 负责封装一个领域中跨实体操作的业务逻辑。App Service 负责封装跨领域实体操作的业务逻辑。

6. Gateway接口用来隔离技术实现细节，GatewayImpl实现领域层定义的Gate接口，负责数据的CRUD操作，数据库测可以是MySQL、NoSql、Elasticsearch、Redis、甚至Hadoop/HBase等

分层架构、包结构、业务调用关系

下图将COLA分层架构、包结构、业务调用关系，整合在一张图中。

COLA分层架构、包结构、以及业务调用关系图

- END -

往期回顾

◆一款功能强大、高颜值、官方出品的Redis可视化工具

◆Flink+Clickhouse在广投集团实时数仓的最佳实践

◆腾讯超大 Apache Pulsar 集群的客户端性能调优实践

◆爬虫基本原理介绍、实现以及问题解决

◆DDD领域驱动设计实战-服务和数据在微服务各层协作的最佳实践

技术交流，请加微信： jiagou6688 ，备注：Java，拉你进架构群