本文将对比分析DDD分层架构、整洁架构、六边形架构。
整洁架构
又名“洋葱架构”（看图就懂），体现了分层思想。
同心圆代表应用软件的不同部分，由内到外依次是
- 领域模型
- 领域服务
- 应用服务
- 容易变化的内容
比如用户接口和基础设施。
该架构最主要原则：依赖原则，它定义了各层依赖关系，越往内依赖越低，代码级别越高，能力越核心。外圈代码依赖只能指向内圈，内圈无需知道外圈任何情况。
职能划分
- 领域模型
实现领域内核心业务逻辑，封装了企业级业务规则。领域模型的主体是实体（可以是一个带方法的对象，也可以是一个数据结构和方法集合）。 - 领域服务
实现涉及多个实体的复杂业务逻辑。 - 应用服务
实现与用户操作相关的服务组合与编排，包含了应用特有的业务流程规则，封装和实现了系统所有用例。最外层
主要提供适配的能力，分为主动适配和被动适配。
- 主动适配主要实现外部用户、网页、批处理和自动化测试等对内层业务逻辑访问适配
- 被动适配主要是实现核心业务逻辑对基础资源访问的适配，如DB、缓存、文件系统和MQ等。
红圈内的领域模型、领域服务和应用服务一起组成软件核心业务能力。
六边形架构
又名“端口适配器架构”。
- 核心理念
应用通过端口与外部交互 - 红圈内的核心业务逻辑（应用程序和领域模型）与外部资源（包括APP、Web应用以及数据库资源等）完全隔离，仅通过适配器交互。它解决了业务逻辑与用户界面的代码交错问题，很好实现前后端分离。六边形架构各层的依赖关系与整洁架构一样，都是由外向内依赖。
职能划分
系统分为内六边形和外六边形：
- 红圈内六边形
实现应用的核心业务逻辑 - 外六边形
完成外部应用、驱动和基础资源等的交互和访问，对前端应用以API主动适配方式提供服务，对基础资源以依赖反转被动适配的方式实现资源访问
该架构的一个端口可能对应多个外部系统，不同外部系统也可能使用不同适配器，由适配器负责协议转换。这就使得应用程序能够以一致的方式被用户形式使用。
现在，很多声称使用分层架构的团队实际上使用的是六边形架构。这是因为 很多项目都使用了某种形式的依赖注入。并不是说依赖注入天生就是六边形架 构，而是说使用依赖注入的架构自然地具有了端口与适配器风格。
架构模型对比分析
虽然DDD分层架构、整洁架构、六边形架构的架构模型表现形式不同，但设计思想正是微服务架构高内聚低耦合原则的完美体现，而它们身上闪耀的正是以领域模型为中心的设计思想。
红色实线边框用于将核心业务逻辑与外部应用、基础资源进行隔离。
红框内部主要实现核心业务逻辑，但核心业务逻辑也有差异，有属于领域模型，有属于面向用户的用例和流程编排能力。按这种功能差异，在这三种架构划分了应用层和领域层，承担不同业务逻辑。
领域层实现面向领域模型，实现领域模型的核心业务逻辑，属原子模型，需保持领域模型和业务逻辑稳定，对外提供稳定的细粒度领域服务，所以是架构核心。
应用层实现面向用户操作相关的用例和流程，对外提供粗粒度API服务。适配前台应用和领域层，接收前台需求，随时做出响应和调整，尽量避免将前台需求传到领域层。应用层作为配速齿轮位于前台应用和领域层间。
这三种架构都考虑了前端需求的变与领域模型的不变。需求变幻无穷，但变化总是有矩可循的，用户体验、操作习惯、市场环境以及管理流程的变化，往往会导致界面逻辑和流程的多变。但核心领域逻辑基本不大变，领域模型相对稳定，用例和流程则会随外部需求而随时调整。
架构模型通过分层控制需求变化从外到里对系统影响，从外向里受需求影响逐步减小。面向用户的前端可以快速响应外部需求进行调整和发布，应用层通过服务组合和编排来实现业务流程的快速适配上线，减少传到领域层的需求，使领域层保持长期稳定。
这样设计的好处，可保证领域层核心业务逻辑不会因外部需求和流程的变动而调整。
