type
status
date
slug
summary
tags
category
icon
password
DDD分层架构
DDD分层架构中有很重要的依赖原则：每层只能与位于下方的层发生耦合，类似于网络的7层或TCP/IP的4层模型架构，每一层各司其职，并且只关心向下一层的实现，而不会出现各层耦合。
DDD分层架构中包含四层：从上到下分别是用户接口层，应用层，领域层和基础层。
洋葱架构
2008年Jeffrey Palermo已经提出了具有分层思想的洋葱架构，如下图，同心圆代表软件的不同部分，从里向外依次是领域模型，领域服务，应用服务和外层的基础设施和用户终端。
洋葱架构根据依赖原则，定义了各层的依赖关系，越往里依赖程度越低，代码级别越高，越是核心能力。外圆代码依赖只能指向内圆，内圆不需要知道外圆的情况，这种架构也是典型的分层架构，和DDD分层架构一样，都体现了高内聚，低耦合的设计特性。洋葱架构也常作为指导微服务设计的重要架构之一。
六边形架构
2005年Alistair Cockburn提出了六边形架构，在这个架构中，将应用分为内六边形和外六边形两层，内六边形实现应用的核心业务逻辑。外六边形完成外部应用，基础资源等的交互和访问，对于与不同的外部系统交互，由外六边形的适配器负责协议转换，保证内六边形业务逻辑的干净。
这种架构也是典型的分层架构，和DDD分层架构一样，都体现了高内聚，低耦合的设计特性。六边形也常作为指导微服务设计的重要架构之一。
DDD分层协作
DDD各层的主要职责和怎么分工协作如下图：
PO（数据持久化对象）：与数据库字段映射的数据载体
DO（领域对象）：领域模型核心业务对象的载体，包括实体和值对象
DTO（数据传输对象）：用于前端和微服务交互的数据传输载体
用户接口层：主要有facade接口，Assembler转换器
- 微服务面向不同前端时，需要展示的数据可能不同，此时由于需要保持领域核心业务逻辑的稳定，不可能去定制开发各种领域服务和应用服务编排。因此，为避免暴露服务端业务逻辑，防止非必需的字段数据外泄 ，同时保证领域逻辑的干净，用户接口层的facade接口和Assembler转换器就发挥作用了。
- facade接口用于封装应用服务，适配不同前端需要的字段，提供不同要求的服务接口适配。Assembler根据不同前端的数据请求，完成DTO和领域DO对象的组装，转换，完成数据适配。
应用层：
- 应用层连接用户接口层和领域层，主要协调领域层，面向用例和业务流程，协调多个聚合完成服务的组合和编排，在这一层不实现任何业务逻辑，只是很薄的一层
- 如何判定一个东西是否属于业务逻辑？
很简单，只需设想你和产品聊这个事情时，需不需要把这部分信息输入给它？比如接口调用的处理，数据的转换，是否加了缓存等等都不属于产品关心的东西，所以不算是业务逻辑
- 应用层编排成应用服务后，被接口层facade封装，完成接口和数据适配后，以粗粒度向API网关发布服务
- 应用层还负责事件的订阅和发布，以及与其他外部服务的交互，事件的具体实现则在领域层
领域层：
- 领域层位于应用层之下，是领域模型的核心，主要实现领域模型的核心业务逻辑，体现领域模型的业务能力
- 领域层关注实现领域对象的充血模型和聚合本身的原子业务逻辑，至于用户操作和业务流程，则交给应用层去编排。这样设计可以保证领域模型不容易受外部需求变化的影响，保证领域模型的稳定
- 跨多个聚合的领域逻辑在领域层实现，由领域服务组织和协调多聚合的多实体，实现原子业务逻辑
基础层：
- 基础层贯穿了DDD所有层，包括第三方工具，API网关，消息中间件，分布式事务，消息最终一致性能力，数据库，缓存能能力的提供。
- 基础层有仓储模式的代码逻辑，通过仓储接口和仓储实现，解耦领域层和基础层，保证领域核心业务逻辑的干净，降低DB资源变化给领域层带来的影响，这部分内容，请见下回分解。