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