--- id: 5ec5594c-0b94-328a-b4a8-77e393dabd5e title: 领域驱动设计 tags: DDD date: '2026-03-25 12:22:01' sha256: 5b0d078a0f1aa97af8d72fd821db005673594b92f37f673e4102c465cb6f0574 --- ## 软件架构设计模式 + 面向对象型 1. 领域驱动设计(Domain Driven Design，DDD) 1. 业务需求（业务团队）--**<理解>-- **领域建模（领域专家）--<设计>--技术转化（技术团队） 2. 活动记录模式 + 面向过程型 3. 数据驱动设计（表驱动模式，Data Driven Design，DDD） 4. 事务性脚本（事件驱动架构，Event Driven Architecture，EDA） ## 软件程序开发方法 + 面向对象（Object Oriented） + 面向过程（Procedure Oriented） + 测试驱动开发（Test-Driven Development） ## 必要性业务逻辑复杂度（规模）+业务变化频率，如： + 是否以数据为中心，所有操作都是 CRUD？ + 业务逻辑是否只是少量的业务场景和用例？ + 应用功能是否已经稳定？ + 团队是否已经对业务领域足够了解？ ## 建模过程 + 统一语言：限界上下文（领域边界）范围内覆盖业务全周期、建模全过程的通用语言 + 领域划分：领域间，业务架构=业务对象、业务流程、组织结构、业务规则、业务能力 + 领域建模：领域内，产品架构=功能+性能+安全性+... + 服务划分：应用或微服务，应用架构 ## 核心概念 ![](https://cdn.nlark.com/yuque/0/2024/png/2638049/1714459251810-6ecb2dae-a7ec-4374-925c-a98261eab186.png) ### 通用语言（Ubiquitous Language）定义术语，业务代表、产品经理、业务架构师、技术架构师、开发人员、领域专家等各方都说“普通话”，屏蔽“方言”。对齐认知，消除歧义与偏差，提升效率 ### 领域（Domain）确定业务范围与边界，域内根据功能属性和重要程度细划子域（Sub Domain） + 核心域：应用和系统核心竞争力，决定业务是否成功的主要因素，比如电商系统中关注的会员、商品、订单、交易、库存、营销等。 + 通用域：没有太多个性化诉求，同时被多个子域使用的通用功能，比如统一认证和权限管理系统。 + 支撑域：既不包含核心竞争力功能，又不包含通用功能的子域，但该功能子域又是必需的，也就是支撑域，比如某个特定领域的数据字典。 DDD 的核心产物是领域模型（Domain Model），领域模型（计算机世界）拥有自己的属性、行为、状态，并可以与现实世界的业务对象相映射。领域模型之间具备明确的职责划分，领域对象元素之间通过聚合和引用<来关联相应的业务规则，同时反映通用语言中的领域知识。 ### 限界上下文（Bounded Context） > 细胞之所以会存在，是因为细胞膜定义了什么在细胞内、什么在细胞外，并且确定了什么物质可以通过细胞膜定义各领域之间的边界和交互方式，交互方式即上下文映射图（Context Map），是通用语言的技术表现，包括防腐层或统一协议两种模式 + **已发布的语言（Published Language）**：两个上下文使用共同的语言，如SOA服务总线定义的XML模型，或基于共享的文件或数据库。 + **开放主机服务（Open Host）**：即统一协议，上下文之间的服务定义一套包含标准数据结构在内的协议，比如基于HTTP风格的RESTful接口协议。 + **共享内核（Shared Kernel）**：即操作系统管道，两个上下文使用共同的内核作为通用语言，比如两个工程使用同一个 Bean 基础模型库。 + **客户/供应商（Customer/Supplier）**：一个上下文使用另一个上下文的服务，有显著的上下游依赖关系，比如基于 RPC 的服务交互方式**（ThreadLocal？）**。 + **顺从者（Conformist）**：一个上下文使用另一个上下文的服务，但彼此之间的关系并不紧密，比如基于消息传递机制的交互模式**（MQ?）**。 + **防腐层（Anti-Corruption Layer，ACL）**：使用适配层协助上下文交互，如在商品子域和采购子域间提供防腐层将商品变更进行收口，隔离子域内的后端业务实现。 ### 实体（Entity）具有唯一身份标识的对象，且可以在相当长的一段时间内持续变化（如用户、账号、产品）。 + **贫血模型**：类似Bean或者DO对象，一般只有Getter/Setter方法，只作为保存状态或者传递状态，不包含业务逻辑。**只有数据没有行为的对象不是真正的领域对象。** + **充血模型**：封装包含实体相关的所有业务逻辑，既是多个业务属性的载体，又是操作或行为的载体。**DDD中的实体属于充血模型。** ### 值对象（Value Object）只关心属性且是没有标识符的对象，是包含若干用于描述目的、具有整体概念和不可修改属性的集合，以使属性归类更加清晰，概念更加完整（如配置、标签）。值对象在领域模型中是不可变且可以被共享的，当有其他地方需要用到值对象时，可以将其副本作为参数进行传递。值对象与实体的区别于： + **值对象一般依附于实体而存在，是实体属性的一部分。** + **值对象****没有唯一标识****，当任何属性发生变化时，都意味着新的值对象产生。** + **值对象功能单一，一般是贫血模型（即只有读取和写入操作，没有其他逻辑操作）。** ### 领域服务（Domain Service）多个领域对象共同完成的操作和动作进行协调，避免领域逻辑泄露到应用层（无状态）的行为或能力 ### 聚合（Aggregate）使用一个抽象来封装模型中的引用以将领域对象的关联减至最少的行为。在每个行为完成时必须满足聚合内所有实体或值对象满足一致的数据变化（事务）。聚合由两部分组成： + 根实体（聚合根？），是聚合中特定的实体，根实体是聚合中所包含的一个特定实体，是唯一允许外部对象保持对其引用的元素，即聚合的入口。 + 与根实体关联的其他对象：定义聚合内部有什么，描述一个边界及边界内对象之间的引用关系。除根实体外的其他对象有本地标识，但这些标识只有在聚合内部才需要加以区分，外部对象除根实体外看不到其他对象。 ### 工厂（Factory）封装创建复杂对象的实例或聚合的独立对象（与设计模式中的工厂模式的作用类似） ### 资源库（Repository）实现对象的持久化并提供方对象，解耦领域内业务逻辑与底层持久化逻辑。每个聚合类都应该对应一个资源库。资源库将 ORM 框架与领域模型隔离，屏蔽数据访问的技术复杂度（技术上 repository 与 mapper 形成 1对 n 引用, n>1）。 **工厂关注的是对象的创建**，**资源库关心的是已经存在对象的写入和读取**。 ### 领域事件（Domain Event）领域中所发生的重要事件，在事件发生后通常会导致进一步的业务操作，或者在系统其他地方甚至其他系统引起反应，表现形式如 MQ 消息。 ## 分析方法 ### 用例分析法通过业务需求（即输入业务架构）、场景流程等梳理用例，进而规划领域模型（场景->流程->模型） + **收集用例**：从业务能力、业务流程、业务需求描述中进行提取，收集相应的名词、动词、形容词，以及对应的业务场景。 + **提取实体**：从名词中定位出主要实体，如商品、SKU、品类等。 + **提取属性**：从形容词中添加实体属性，如颜色、价格等。 + **添加关联**：从动词或形容词中添加实体和实体之间的关联，如商品“包含”SKU，卖家“开设”“多家”店铺等。 + **完善模型**：识别出初步模型，验证并迭代模型，同时补充用例验证模型、业务流程验证模型。 ### 四色建模法 + **时间记录（Moment-Interval）**：具有**可追溯性**的记录运营或管理数据的时刻或时段对象（如**用粉红色表示**）。 + **人货场（Party-Place-Thing Archetype，PPT）**：代表参与到流程中的参与方、地点、物（如**用绿色表示**）。 + **角色（Role）**：在时间记录与PPT对象（通常是参与方）之间参与的角色（如**用黄色表示**）。 + **描述（Description）**：对PPT对象的一种补充描述（如**用蓝色表示**）。 **某个人（****Party****）的角色（****PartyRole****）在某个地点（****Place****）的角色（****PlaceRole****）用某个东西（****Thing****）的角色（****ThingRole****）做某件事情（****Moment-Interval****）**。 ### 事件风暴法类似头脑风暴的群体建模技术 + **事件**：发生了什么事情，产生了什么结果（如**用橘黄色表示**）。 + **属性**：事件的输入、输出，是对时间的细化描述。 + **命令**：某个动作的发起者，可能是人、外部事件、定时器等（如**用蓝色表示**）。 + **领域**：领域的聚合、内聚、低耦合，聚合内部保证数据的一致性（如**用黄色表示**）。谁在何时基于什么（输入）做了什么（命令），产生了什么（输出），影响了什么（事件），最后聚合成了什么（领域） ## DDD 分层架构 ![](https://cdn.nlark.com/yuque/0/2024/png/2638049/1714460119257-e31df383-bd25-414d-afae-452d2eec1dd3.png) + **展示层（Facade Layer）**：负责与不同用户和应用之间的交互协议和数据格式的转换，因此它又叫用户接口层。 + **应用层（Application Layer）**：**负责展示层与领域层之间的协调，与其他系统的应用层进行交互的必要渠道**，负责对领域层组件进行简单封装，例如事务、调用应用程序的任务。应用层要尽量简单，其服务及方法一般以用例为对应关系，通常一个用例对应到一个应用层的服务方法，方法中不包含业务规则或者知识，不保留业务对象的状态，只保留应用任务的进度状态，更注重业务能力或者业务流程的相关展示。主要通过调用领域层和基础设施层来完成协调。 + **领域层（Domain Layer）**：领域层是DDD的核心，包含一些核心概念，如领域实体、值对象、领域服务、聚合，以及它们之间的关系。它主要负责表达业务概念、业务状态信息及业务规则，具体表现形式是领域模型。DDD提倡充血模型，即尽量将业务逻辑归属到领域对象上。 + **基础设施层（Infrastructure Layer）**：向其他层提供通用的技术能力，为应用层传递消息（如API网关等），为领域层提供持久化机制（如数据库资源、中间件交互等），屏蔽技术底座能力（如底层服务的健康度检查、配置参数等）及其他通用的工具类服务。 DDD分层原则。 + 无环依赖原则：组件的依赖关系中没有环路，如果出现，则需要打破循环依赖。 + 稳定依赖原则：被依赖者应该比依赖者更稳定，同时组件的抽象程度应该与其稳定程度保持一致。一个稳定的组件应该是抽象的，这样便于扩展。 + 依赖倒置原则：高层次的模块不应该依赖低层次的模块，它们都应该依赖抽象。抽象不应该依赖具体，具体应该依赖抽象。 ## DDD 价值 1. 通用语言：团队成员在有界上下文中有意识地以所有干系人都能理解的通用语言为交流工具，在交流过程中形成领域概念，然后将这些概念设计成领域模型。 2. 业务沉淀：DDD 不以人为中心，而以业务为中心通过承接业务架构的业务流程和业务能力，通过领域知识进行转化反哺业务架构和应用架构。 3. 边界清晰的应用划分：用领域模型来界定哪些需求是合理，以及应该在什么地方实现。不断拉齐团队成员对需求的认知，让设计更加清晰和规范，分而治之，控制规模。 4. 关注点分离：领域模型与数据模型分离，业务复杂度与技术复杂度分离，保持清晰的结构以应对不可预测的挑战（技术专家担任领域专家最大挑战就是受面向对象影响至深，难以区别业务对象与技术实体） 5. 团队协同：业务人员和设计人员的共同参与有助于创建可被普遍理解的通用领域模型，并用该模型来沟通业务需求、数据实体和过程模型。 6. 模型可扩展：领域模型将业务需求到领域服务进行很好的转化，是微服务及项目落地开发的纽带，其可扩展且易维护的特性，提高相应应用服务可重用性和可测试性。 ## 参考资料 [领域驱动设计](https://tonydeng.github.io/2022/11/06/domain-driven-design/)