在DDD的项目实践中，我们会使用一些常用的架构模式，来进行系统架构的合理设计。　

以下是DDD常用架构模式：

• DDD分层架构

• 整洁架构

• 六边形架构

• DDD分层架构 vs 整洁架构 vs 六边形架构

• Event Driven 架构

• CQRS(Command Query Responsibility Segregation) 架构

• 微服务内领域事件设计模式

• 微服务间领域事件设计模式

DDD分层架构

DDD 分层架构包含用户接口层、应用层、领域层和基础层。

整洁架构

整洁架构又名“洋葱架构”。整洁架构的层就像洋葱片一样，它体现了分层的设计思想。在整洁架构里，同心圆代表应用软件的不同部分，从里到外依次是领域模型、领域服务、应用服务和最外围的容易变化的内容，比如用户界面和基础设施。

整洁架构最主要的原则是依赖原则，它定义了各层的依赖关系，越往里依赖越低，代码级别越高，越是核心能力。外圆代码依赖只能指向内圆，内圆不需要知道外圆的任何情况。

在洋葱架构中，各层的职能是这样划分的：

• 领域模型实现领域内核心业务逻辑，它封装了企业级的业务规则。领域模型的主体是实体，一个实体可以是一个带方法的对象，也可以是一个数据结构和方法集合。
• 领域服务实现涉及多个实体的复杂业务逻辑。
• 应用服务实现与用户操作相关的服务组合与编排，它包含了应用特有的业务流程规则，封装和实现了系统所有用例。
• 最外层主要提供适配的能力，适配能力分为主动适配和被动适配。主动适配主要实现外部用户、网页、批处理和自动化测试等对内层业务逻辑访问适配。被动适配主要是实现核心业务逻辑对基础资源访问的适配，比如数据库、缓存、文件系统和消息中间件等。
• 红圈内的领域模型、领域服务和应用服务一起组成软件核心业务能力。

六边形架构

六边形架构又名“端口适配器架构”。

六边形架构的核心理念是：应用是通过端口与外部进行交互的。

六边形架构将系统分为内六边形和外六边形两层，这两层的职能划分：

• 红圈内的六边形实现应用的核心业务逻辑；
• 外六边形完成外部应用、驱动和基础资源等的交互和访问，对前端应用以 API 主动适配的方式提供服务，对基础资源以依赖倒置被动适配的方式实现资源访问。

DDD分层架构 vs 整洁架构 vs 六边形架构

三种微服务架构模型的对比和分析

• 虽然 DDD 分层架构、整洁架构、六边形架构的架构模型表现形式不一样，但这三种架构模型的设计思想正是微服务架构高内聚低耦合原则的完美体现，而它们身上闪耀的正是以领域模型为中心的设计思想
• 架构模型通过分层的方式来控需求变化从外到里对系统的影响，从外向里受需求影响逐步减小。
• 面向用户的前端可以快速响应外部需求进行调整和发布，灵活多变
• 应用层通过服务组合和编排来实现业务流程的快速适配上线，减少传导到领域层的需求，使领域层保持长期稳定。

 

Event Driven 架构实现原理

介绍一个保险承保业务过程中有关领域事件驱动架构的例子。

一个保单的生成，经历了很多子域、业务状态变更和跨微服务业务数据的传递。这个过程会产生很多的领域事件，这些领域事件促成了保险业务数据、对象在不同的微服务和子域之间的流转和角色转换。

在下面这张图中，列出了几个关键流程，用来说明如何用领域事件驱动设计来驱动承保业务流程。

 

 

CQRS(Command Query Responsibility Segregation) 架构

本质上，CQRS也是一种读写分离的机制

两种实现方式：

1. CQ 两端数据库共享， CQ 两端只是在上层代码上分离； 这种做法，带来的好处是可以让我们的代码读写分离，更好维护，且没有 CQ 两端的数据一致性问题，因为是共享一个数据库的。这种架构很实用，既兼顾了数据的强一致性，又能让代码好维护。  

2. CQ两端数据库和上层代码都分离，然后Q的数据由C端同步过来，一般是通过Domain Event进行同步。同步方式有两种，同步或异步，如果需要CQ两端的强一致性，则需要用同步；如果能接受CQ两端数据的最终一致性，则可以使用异步。

 

微服务内领域事件设计模式

 

微服务间领域事件设计模式

领域事件处理包括：事件构建和发布、事件数据持久化、事件总线、消息中间件、事件接收和处理等

 

 

 

标签：架构,领取,适配,领域,整洁,六边形,DDD
来源： https://blog.csdn.net/u011537073/article/details/114190219