DDD领域驱动设计微服务架构——知识点条记
目录一、架构概览与演变
1.1 整洁架构：编辑1.2 六边形架构
1.3 DDD 分层架构
1.4 三层架构
1.5 三层架构到DDD架构的演变
二、DDD架构代码目录详解
2.1 用户接口层
2.2 应用层
2.3 领域层
2.4 底子层
2.5 各层代码调用案例展示
一、架构概览与演变
1.1 整洁架构：https://i-blog.csdnimg.cn/direct/da9dba48be124331ad7262194fe7da9a.png1.2 六边形架构
https://i-blog.csdnimg.cn/direct/05fe41c334a6412c92642f7cb664b6a5.png
1.3 DDD 分层架构
https://i-blog.csdnimg.cn/direct/2508d6b9567648d584a178f8d7f6e489.png
[*]接口层负责与用户、程序、主动化测试、批处置惩罚脚本交互。
[*]应用层负责对领域层的多个聚合进行协调，平凡地说就是对微服务之间进行组合编排，但不负责具体的微服务实现逻辑，实现逻辑应该放在领域层。应用服务还可以进行安全认证、权限校验、事务控制、发送或订阅领域事故等。
[*]领域层实现微服务焦点业务逻辑，包含聚合根、实体、值对象、领域服务等领域对象（领域模型），其中的实体采用充血模型（对象的方法和数据不分离，与之对应的是血虚模型）实现；领域服务负责组合聚合内的多个实体来实现复杂业务。
[*]底子层贯穿全部层，为其他层提供三方工具、驱动、MQ、网关、文件操作、缓存、数据库等底子服务，封装底子服务的特点实现了以上三层的解耦。
1.4 三层架构
传统三层架构包含Controller层、Service层、Dao层，增编削查的流程大概如下：
https://i-blog.csdnimg.cn/direct/129bc1495a83448cba7b9f960b3a7e5b.png
但其实可以发现，Service层就是充当了中心人，Controller明显可以直接调用Dao，但真实业务场景往往更复杂，前后端交互是用Json（对象）交互，由于有时候前后端须要交互的数据并不是对象全部的字段，只是其中某些字段，那我们传输时只须要传这几个字段就行了，所以须要诞生PO、VO、DTO，这就不再是纯粹的三层架构了。
[*]VO 是Value Object 的缩写，值对象，位于视图层，每一个字段与视图层所须要的字段对应
[*]DTO是Data Transfer Object 的缩写，数据传输对象，在视图层和服务层之间传输用来转换从PO到VO，大概从VO到PO的中心对象
[*]PO 是Persistent Object 的缩写，持久化对象，位于持久层，每一个字段，与数据库相对应
[*] DO（Domain Object）领域对象，微服务运行时的实体，是焦点业务的载体，出如今领域模型中。
1.5 三层架构到DDD架构的演变
https://i-blog.csdnimg.cn/direct/96f23192dba9481fa51d415cf9861c67.png
[*] 在三层架构中的业务逻辑层和数据访问层发生了较多的改变。
[*]DDD架构在业务接口层引入DTO，用户接口可以更灵活的交互数据。
[*]三层架构的业务层往往是混乱复杂的，DDD架构将其拆分到了应用层和领域层，应用层响应前端，调用领域层的焦点业务进行服务。
[*]在最底层，三层架构使用Dao访问数据，DDD架构使用仓储模式Repository，通过依赖倒置实现底子资源解耦，像驱动、三方工具包等公共资源都被归到了底子层。
二、DDD架构代码目录详解
DDD分层架构、六边形架构、整洁架构都实现了前后端分离，内部负责业务逻辑、外部负责交互用户和底子资源，差别的是DDD分离出来了应用层，来充当API角色，解决了传统三层架构中Service层混乱无序的问题，以下是一个经典DDD架构模型代码目录：https://i-blog.csdnimg.cn/direct/9048aae9cc90436585529d1ff8f88b70.png
2.1 用户接口层
interfaces存放与前端交互，展示数据的代码。重要处置惩罚用户的Restful哀求，剖析设置文件，通报数据往应用层。
https://i-blog.csdnimg.cn/direct/5ddd8222db5447968a5d1e289508eabd.png
[*]assemble： 实现领域对象和DTO之间的数据交互。
[*]dto：进行数据传输，实现了领域对象与外界的隔离。
[*]facade：提供粗粒度的API，委托和分发用户的哀求给应用服务。
2.2 应用层
application存放与微服务组合和编排相关代码。
https://i-blog.csdnimg.cn/direct/46e341419cd442e3b8cf03d4974d0f2d.png
[*]event：与事故相关，负责事故的发布与订阅。
[*]Service：对领域服务或外部应用服务进行封装、编排或组合，一样平常包含多个应用服务类。
2.3 领域层
https://i-blog.csdnimg.cn/direct/ec1d4a70fba048cdbe076624e8c11f78.png
domain存放焦点业务逻辑代码。包含多个聚合代码包，聚合包内包括实体、方法、领域服务和事故等代码。
[*]aggregate（聚合）：是高内聚的业务逻辑封装，聚合间代码边界清晰，方便微服务重组。
[*]entity（实体）：存放聚合根、实体、值对象、工厂模式相关代码。采用充血模式，同一实体相关的业务逻辑都在实体类代码中实现。跨实体的业务逻辑代码在领域服务中实现。
[*]event（事故）：存放事故实体以及与事故活动相关的业务逻辑代码。
[*]Service（领域服务）：存放领域服务代码。包含一个或多个领域服务类，封装成实体或方法后向上层提供调用接口。
[*]repository（仓储）：存放所在聚合的查询或持久化领域对象的代码，通常包括仓储接口和仓储实现方法。一个聚合对应一个仓储。
2.4 底子层
infrastructure存放底子资源代码。为别的各层提供的通用技术能力、三方软件包、数据库服务、设置、网关等底子资源服务。
https://i-blog.csdnimg.cn/direct/cab08726f6464354881ae8a101dbd0b7.png
[*]Config：重要存放设置相关代码。
[*]Util：重要存放平台、开发框架、消息、数据库、缓存、文件、总线、网关、第三方类库、通用算法等底子代码，你可以为差别的资源种别创建差别的子目录。
2.5 各层代码调用案例展示
DDD分层架构不允许服务跨层调用，服务逐层封装
https://i-blog.csdnimg.cn/direct/0c892d9e461043838f938cc9426683a0.png
[*]底子层的重要对象是 PO 对象。我们须要先创建 DO 和 PO 的映射关系：大多数环境下 PO 和 DO 是一一对应的。但也有 DO 和 PO 多对多的环境，在 DO 和 PO 数据转换时，须要进行数据重组。
[*]领域层的重要对象是 DO 对象。DO 是实体和值对象的数据和业务举动载体，承载着底子的焦点业务逻辑。通过 DO 和 PO 转换，我们可以完成数据持久化和初始化。
[*]应用层的重要对象是 DO 对象。假如须要调用别的微服务的应用服务，DO 会转换为 DTO，完成跨微服务的数据组装和传输。用户接口层先完成 DTO 到 DO 的转换，然后应用服务吸取 DO 进行业务处置惩罚。假如 DTO 与 DO 是一对多的关系，这时就须要进行 DO 数据重组。
[*]用户接口层会完成 DO 和 DTO 的互转，完成微服务与前端应用数据交互及转换。Facade 服务会对多个 DO 对象进行组装，转换为 DTO 对象，向前端应用完成数据转换和传输。
[*]前端应用重要是 VO 对象。展现层使用 VO 进行界面展示，通过用户接口层与应用层采用 DTO 对象进行数据交互。
https://i-blog.csdnimg.cn/direct/7471e32e4764459db6b809ffade4c803.png
参考资料领域驱动实践架构分析与代码设计_l领域驱动实践总结-CSDN博客
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]