在我的博客阅读本文
1. 传统做法
2. DDD的一种实现
代码结构:
一图流:
- 将业务决策从庞大的service中剥离出来,拆分为若干领域实体,将业务决策交给一个个的领域实体,由application层进行统一的委派,有效梳理业务,结构分明,降低代码维护难度,新同学更易上手。
- 防腐层设计,业务与技术解耦,引导系统逐渐走上业务与技术分离的架构路线,保证业务逻辑在领域模型中得到不断重构和发展,成为系统的核心资产。
3. COLA的做法
模块划分:
adapter模块 | 定于对外透出服务的方式,gPPC,Http等 |
---|---|
client模块 | 定义对外透出服务的API |
app模块 | 实现client模块中定义的对外提供的API |
domain模块 | 领域服务 & 领域网关 |
infrastructure模块 | 具体技术实现 |
一图流:
3.1. adapter模块代码结构
adapter模块承载了系统对外提供服务的适配类,如果当前服务提供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基础设施层来讲,分为多种技术实现。
这里的防腐层设计,业务与技术解耦,引导系统逐渐走上业务与技术分离的架构路线,保证业务逻辑在领域模型中得到不断重构和发展,成为系统的核心资产。
除此以外,服务暴露的RPC服务,也是写在这里。
3.6. DDD与非DDD在COLA中的差异
差异主要在与Domain模块:
- DDD的Domain模块应该有对应的领域服务,系统的核心在这一块
- 非DDD的Domain模块比较弱,只有一些基本职能,包括定义一些上层接口来对基础设施层做防腐,主要业务资产在App模块。
参考资料
COLA 4.0:应用架构的最佳实践