记一次COLA架构的实践

在我的博客阅读本文

1. 传统做法

2. DDD的一种实现

代码结构：

一图流：

• 将业务决策从庞大的service中剥离出来，拆分为若干领域实体，将业务决策交给一个个的领域实体，由application层进行统一的委派，有效梳理业务，结构分明，降低代码维护难度，新同学更易上手。
• 防腐层设计，业务与技术解耦，引导系统逐渐走上业务与技术分离的架构路线，保证业务逻辑在领域模型中得到不断重构和发展，成为系统的核心资产。

3. COLA的做法

模块划分：

adapter模块	定于对外透出服务的方式，gPPC，Http等
client模块	定义对外透出服务的API
app模块	实现client模块中定义的对外提供的API
domain模块	领域服务 & 领域网关
infrastructure模块	具体技术实现

一图流：

3.1. adapter模块代码结构

adapter模块承载了系统对外提供服务的适配类，这里只暴露gRPC的接口，如果当前服务提供Restful，也可以定义在这里。

3.2. client模块代码结构

client模块定义了对外透出的接口，可以作为SDK提供出去。

这里进一步划分了几个包：

api	服务对外透出的接口
convert	转换类
dto.command	新增，修改，删除操作参数
dto.data	查询回调参数
dto.event	事件相关参数
dto.query	查询操作参数

3.3. app模块代码结构

app模块实现了client模块定义的接口，也就是对外提供的api的具体实现。

这里进一步划分了几个包：

consumer	消息消费
convert	转换类
executor	命令模型，所有增删改操作
executor.query	查询模型，所有查询操作

每一个实现（图中的xxxServiceImpl），都是委派若干executor来完成，这样做可以将一个庞大的service解耦成若干小类和方法，避免大而全的一个类。

executor按照CQRS的思想，进一步划为“命令模型”与“查询模型”。

3.3.1. 关于CQRS架构

CQRS从读写职责角度对请求的功能进行分类。

• Command命令模型

当界面的表单数据提交到后端时就会有写入表单数据的命令，之后将命令中的DTO提取出来，进行业务逻辑检查或计算，持久化。这条路线称为Command模型路线。

命令是客户端让服务器做事情，是从客户端向服务器后端发出写入操作命令，通常会改变后端模型的状态。

• Query查询模型

搜索只是从搜索库中获取搜索的结果，并没有任何复杂的业务逻辑计算。

查询是服务器后端向客户端返回结果。

这样划分的好处：

• 在DDD中，领域模型可以根据DDD原则进行建立，而查询模型则根据数据查询要求进行建立，二者模型设计依据不同，应该区分开，也就是区分开领域驱动设计&数据驱动设计。
• 在分开设计后，可以单独针对查询模型使用与命令模型不一样的存储引擎，比如命令模型使用MySQL，查询模型使用ElasticSearch，Redis等，这里需要注意不同存储引擎的同步。

3.4. domain模块代码结构

domain模块定义了当前领域服务的能力，模型，与领域网关。

领域网关这个概念是指当前服务的所有持久化以及查询的接口，有点类似DDD的仓储接口。

这里进一步划分了几个包：

gateway	领域网关接口
model	领域模型实体
ability	领域服务（能力），是一个可选项，非DDD工程可以没有

3.5. infrastructure模块代码结构

infrastructure定义了当前服务所有具体的技术实现，主要是domain模块中定义的gateway的实现。

按照网关实现不同，这里进一步划分了几个包：

database	数据库网关相关实现
rpc	远程过程调用网关相关实现
xxx.dataobject	数据库/RPC调用需要用到的类

这样，对于domain层定义了网关接口来讲，它并不关心具体的技术实现；对于infrastructure基础设施层来讲，分为多种技术实现。

这里的防腐层设计，业务与技术解耦，引导系统逐渐走上业务与技术分离的架构路线，保证业务逻辑在领域模型中得到不断重构和发展，成为系统的核心资产。

3.6. DDD与非DDD在COLA中的差异

差异主要在与Domain模块：

• DDD的Domain模块应该有对应的领域服务，系统的核心在这一块
• 非DDD的Domain模块比较弱，只有一些基本职能，包括定义一些上层接口来对基础设施层做防腐，主要业务资产在App模块。

参考资料

COLA 4.0：应用架构的最佳实践