系统架构设计——DDD设计框架基本学习

摘要

最近DDD设计很火，但是刚刚入门还是很懵，通过的学习DDD项目设计的结构目录来实现对DDD设计理解同时也是为大家在公司能够看懂公司的DDD项目结构目录做一个参考和学习。同时后期本人将推出更多的对DDD设计的理解。同时提供一个DDD设计的模板框架：https://github.com/2462612540/Senior-Architect/tree/a_1.0/Springcloud_microservice_ddd

DDD设计的四层

参考官方架构草图，DDD总体结构分为四层  :  Infrastructure(基础实施层)，Domain(领域层)，Application(应用层)，Interfaces(表示层，也叫用户界面层或是接口层)。

 对于DDD的设计而言，最重要的是如何去划分领域，划分好边界。在代码设计上，之前有看到过大佬用模块(Modules)来进行上下文界定和划分。而对于微服务而言，就非常适合从业务上去划分以上的各个Modules，划分好各个业务板块。

在实际开发中，我们一般会采用模块来表示一个领域的界限上下文，比如:

抽奖上下文:com.xjl.business.lottery.*

风控上下文:com.xjl.business.riskcontroller.*

奖品上下文:com.xjl.business.prize.*

活动资格上下文:com.xjl.business.qualification.*

库存上下文:com.xjl.business.stock.*


对于模块内的组织结构，一般情况下我们是按照领域对象、领域服务、领域资源库、防腐层等组织方式定义的。

领域对象-值对象:com.xjl.business.lottery.domain.valobj.*

领域对象-实体:com.hafiz.business.lottery.domain.entity.*

领域对象-聚合根: com.xjl.business.lottery.domain.aggregate.*

领域服务:com.xjl.business.lottery.domain.service.*

领域资源库:com.xjl.business.lottery.domain.repo.*

领域防腐层:com.xjl.business.lottery.domain.facade.*

 微服务 + DDD，首先是从微服务的角度(如何划分微服务)考虑去划分大的业务模块，每一个微服务都应该是一个可以单独部署，各司其职的模块；而在微服务实际开发中，结合DDD的思想去划分所有属于自己的领域。

项目框架总体设计

Infrastructure(基础实施层)

Infrastructure 层 :  基础实施层，向其他层提供通用的技术能力(比如工具类,第三方库类支持,常用基本配置,数据访问底层实现).基础实施层主要包含以下的内容:

• 为应用层传递消息（比如通知)
• 为领域层提供持久化机制（最底层的实现)为用户界面层提供组件配置)
• 基础设施层还能够通过架构框架来支持四个层次间的交互模式。

Domain(领域层)

Domain层 : 主要负责表达业务概念,业务状态信息和业务规则；是整个系统的核心层,几乎全部的业务逻辑会在该层实现。Domain层是整个系统的核心层,几乎全部的业务逻辑会在该层实现。领域模型层主要包含以下的内容:

• 实体(Entities):具有唯一标识的对象
• 值对象（value objects):无需唯一标识的对象
• 领域服务(Domain Services):一些行为无法归类到实体对象或值对象上,本质是一些操作,而非事物聚合/聚合根(Aggregates,Aggregate Roots):
• 聚合是指一组具有内聚关系的相关对象的集合,每个聚合都有一个root和boundary工厂(Factories):创建复杂对象,隐藏创建细节
• 仓储(Repository):提供查找和持久化对象的方法

Application(应用层)

Application层 :  相对于领域层,应用层是很薄的一层,应用层定义了软件要完成的任务,要尽量简单。它不包含任务业务规则或知识,为下一层的领域对象协助任务、委托工作。它没有反映业务情况的状态,但它可以具有反映用户或程序的某个任务的进展状态。对外为展现层提供各种应用功能(service）。对内 调用领域层（领域对象或领域服务）完成各种业务逻辑任务(task)。这一层也很适合写一些任务处理,日志监控。

注 : 这里图里面所说的对内对外，对程序而言，事实上是从展现层调用应用层，应用层调用领域层，领域层或调用基础设施层。

Interfaces(表示层，也叫用户界面层或是接口层)

Interfaces层 : 负责向用户显示信息和解释用户命令，请求应用层以获取用户所需要展现的数据(比如获取首页的商品数据)。发送命令给应用层要求其执行某个用户命令(实现某个业务逻辑,比如用户要进行转账)用户界面层应该包含以下的内容:

• 数据传输对象(Data Transfer 0bject):DTO也常被称作值对象，Vo,实质上与领域层的vO并不相同
• DTo是数据传输的载体,内部不应该存在任何业务逻辑,通过DTO把内部的领域对象与外界隔离。
• 装配(Assembler):实现DTO与领域对象之间的相互转换,数据交换,因此Assembler几乎总是同DTO一起出现。
• 表面,门面(Facade): facade的用意在于为远程客户端提供湘粒度的调用接口。它的主要工作就是将一个用户请求委派给一个或多个Service进行处理,也就是我们常说的Controller

总结

无论我们代码结构如何规划，也并非一成不变，应该从实际出发，去思考划分结构的意义。此例子是对于微服务+DDD反应到实际开发，代码的结构设计上的一种初步的思考与探索,一个样板工程，不应该成为我们对实际DDD思考与设计的限制。

• 微服务架构设计，一个微服务应该就是一个可单独部署，可运行的应用，也就是微服务最小的运行单元。
• 微服务本身内部高度内聚，微服务与微服务之间低耦合。
• 首先对于应用划分上，就应该想清楚每个微服务的职责，每个微服务服务内部建立起自己的依赖，完成自己的职责和业务。
• 微服务与微服务之间交互通过HTTP或RPC接口调用，降低微服务之间代码实现和业务的耦合。
• 微服务的实现不应该受限某程序语言(或Java，或Go，或Python)，不应该受限于某框架(或SpringCloud，或Dubbo，或各种RPC框架等等)。
• 我的代码结构是对于一个微服务本身(即应用)划分的，领域是对于微服务内部本身而言的，即这个微服务涉及哪些领域。
• 首先从大的方向去划分每一个微服务，然后再从每一个微服务确定所包含的领域，领域的边界，等等。
• 比如划分了一个 认证授权服务，那么 领域可能有 用户，权限；实体可能有角色，资源等等。领域行为有授权登录，用户退出，授权等等。

 博文参考

一个微服务+DDD(领域驱动设计)的代码结构示例_如果频繁就私信一下呢-

DDD领域驱动设计实战-分层架构及代码目录结构_JavaEdge全是干货的技术号