DDD（领域驱动设计）系列主题：DDD常用架构模式
在DDD的项目实践中，我们会使用一些常用的架构模式，来进行系统架构的合理设计。
以下是DDD常用架构模式：
- DDD分层架构
-
整洁架构
-
六边形架构
-
DDD分层架构 vs 整洁架构 vs 六边形架构
-
Event Driven 架构
-
CQRS(Command Query Responsibility Segregation) 架构
-
微服务内领域事件设计模式
-
微服务间领域事件设计模式
DDD分层架构
DDD 分层架构包含用户接口层、应用层、领域层和基础层。
分层架构的一个重要原则是每层只能与位于其下方的层发生耦合。
分层架构可以简单分为两种，即严格分层架构和松散分层架构。在严格分层架构中，某层只能与位于其直接下方的层发生耦合，而在松散分层架构中，则允许某层与它的任意下方层发生耦合。
分层架构的优点，Martin Fowler在《Patterns of Enterprise Application Architecture》一书中给出了答案：
- 开发人员可以只关注整个结构中的某一层。
- 可以很容易的用新的实现来替换原有层次的实现。
- 可以降低层与层之间的依赖。
- 有利于标准化。
- 利于各层逻辑的复用
适当的分层体系结构将开发层面进行隔离，这些层不受其他层的更改的影响，从而使重构更加容易。划分任务并定义单独的层是架构师面临的挑战。当需求很好地适应了模式时，这些层将易于解耦或分层开发。
使用场景：
- 需要快速构建的新应用程序
- 需要严格的可维护性和可测试性标准的应用
整洁架构
整洁架构又名“洋葱架构”。整洁架构的层就像洋葱片一样，它体现了分层的设计思想。在整洁架构里，同心圆代表应用软件的不同部分，从里到外依次是领域模型、领域服务、应用服务和最外围的容易变化的内容，比如用户界面和基础设施。
整洁架构最主要的原则是依赖原则，它定义了各层的依赖关系，越往里依赖越低，代码级别越高，越是核心能力。外圆代码依赖只能指向内圆，内圆不需要知道外圆的任何情况。
在洋葱架构中，各层的职能是这样划分的：
- 领域模型实现领域内核心业务逻辑，它封装了企业级的业务规则。领域模型的主体是实体，一个实体可以是一个带方法的对象，也可以是一个数据结构和方法集合。
- 领域服务实现涉及多个实体的复杂业务逻辑。
- 应用服务实现与用户操作相关的服务组合与编排，它包含了应用特有的业务流程规则，封装和实现了系统所有用例。
- 最外层主要提供适配的能力，适配能力分为主动适配和被动适配。主动适配主要实现外部用户、网页、批处理和自动化测试等对内层业务逻辑访问适配。被动适配主要是实现核心业务逻辑对基础资源访问的适配，比如数据库、缓存、文件系统和消息中间件等。
- 红圈内的领域模型、领域服务和应用服务一起组成软件核心业务能力。
六边形架构
六边形架构又名“端口适配器架构”。
六边形架构的核心理念是：应用是通过端口与外部进行交互的。
六边形架构将系统分为内六边形和外六边形两层，这两层的职能划分：
- 红圈内的六边形实现应用的核心业务逻辑；
- 外六边形完成外部应用、驱动和基础资源等的交互和访问，对前端应用以 API 主动适配的方式提供服务，对基础资源以依赖倒置被动适配的方式实现资源访问。
DDD分层架构 vs 整洁架构 vs 六边形架构
三种微服务架构模型的对比和分析
- 虽然 DDD 分层架构、整洁架构、六边形架构的架构模型表现形式不一样，但这三种架构模型的设计思想正是微服务架构高内聚低耦合原则的完美体现，而它们身上闪耀的正是以领域模型为中心的设计思想
- 架构模型通过分层的方式来控需求变化从外到里对系统的影响，从外向里受需求影响逐步减小。
- 面向用户的前端可以快速响应外部需求进行调整和发布，灵活多变
- 应用层通过服务组合和编排来实现业务流程的快速适配上线，减少传导到领域层的需求，使领域层保持长期稳定。
事件驱动架构（Event Driven Architecture - EDA）
事件驱动架构 (Event-driven architecture) 是一种软件架构模式。对于事件驱动系统而言，事件的捕获、通信、处理和持久保留是解决方案的核心结构。这和传统的请求驱动模型有很大不同。
许多现代应用都采用了事件驱动设计。因为事件驱动本身是一种编程架构方法，而不是一种编程语言， 因此事件驱动应用可以用任何一种编程语言来创建。事件驱动架构可以最大程度减少耦合度，因此是现代化分布式应用架构的理想之选。
事件驱动架构采用松散耦合方式，因为事件发起者并不知道哪个事件使用者在监听事件，而且事件也不知道其所产生的后续结果。
可以从两个方面来理解 EDA：
- EDA 是一种侧重于以生成/消费为基础的异步通信的架构模式。这主要对照于传统的基于线程的同步系统。
- EDA 是一种以事件 (event)为核心，提供事件产生，路由，消费已经结果回调等机制的架构模式。
介绍一个保险承保业务过程中有关领域事件驱动架构的例子。
一个保单的生成，经历了很多子域、业务状态变更和跨微服务业务数据的传递。这个过程会产生很多的领域事件，这些领域事件促成了保险业务数据、对象在不同的微服务和子域之间的流转和角色转换。
在下面这张图中，列出了几个关键流程，用来说明如何用领域事件驱动设计来驱动承保业务流程。
CQRS(Command Query Responsibility Segregation) 架构
命令查询的责任分离Command Query Responsibility Segregation (简称CQRS)模式是一种架构体系模式,能够使改变模型的状态的命令和模型状态的查询实现分离。
本质上，CQRS是一种读写分离的机制
两种实现方式：
2. CQ两端数据库和上层代码都分离，然后Q的数据由C端同步过来，一般是通过Domain Event进行同步。同步方式有两种，同步或异步，如果需要CQ两端的强一致性，则需要用同步；如果能接受CQ两端数据的最终一致性，则可以使用异步。
微服务内领域事件设计模式
微服务间领域事件设计模式
领域事件处理包括：事件构建和发布、事件数据持久化、事件总线、消息中间件、事件接收和处理等
----------------------------------
大家好，我是流水，一个资深的IT从业人员和架构师. 非常高兴您能搜索到，并看到这篇文章，希望这篇文章的内容能给您带来新的知识和帮助。
也欢迎扫描以下的二维码或微信搜索 “superxtech”，关注我的微信公众号 , 我会把更多更好的IT领域技术知识带给您！
----------------------------------