领域驱动设计

DDD 是什么

传统的 MVC

MVC 是模型(Model)、视图(View)、控制器(Controller)的简写，其核心思想是通过将业务逻辑、数据、显示分离来组织代码，其中 Model 是数据库模型，View 层负责视图展示，而业务逻辑在 Controller 中实现（一般由众多 Service 来辅助实现）。

对于小型，且业务逻辑不复杂的系统，MVC 简单高效，不失为一个合适的设计架构。但是随着业务迭代，逻辑膨胀，MVC会开始力不从心，主要有几个原因：

1. MVC 是完全面向技术的架构设计，分层的系统设计方便了开发者，但是完全没有考虑业务，一股脑把所有业务逻辑放到了 Service 层
2. MVC模式天然切割了数据和行为，然后用数据库实现数据，用服务实现行为，容易造成需求的首尾分离
3. 缺乏明确的边界划分，至少在顶层设计层面没有边界划分的规范要求，更多地是靠技术负责人根据经验进行划分，大规模团队协作容易出现职责不清晰、分工不明确的问题

DDD 定义

DDD 全称 Domain-Driven-Design，领域驱动设计，是一种模型驱动设计的方法，通过领域模型捕捉领域知识，使用领域模型构造更易维护的软件。模型在领域驱动设计中，有三个重要用途：

1. DDD 通过对业务需求的分析和领域模型设计，划分出领域、子领域、限界上下文，指导了系统的架构设计，直接反映软件实现的结构
2. DDD 聚焦于领域模型，只反映业务，和任何技术实现无关，降低了业务和技术的耦合度，以模型为基础形成团队的统一语言，将复杂的问题分而治之，指导团队成员分工协作
3. 领域模型设计使得模型与业务的真实世界保持一致，促使业务知识通过模型得以传递和沉淀

DDD在构建复杂业务的软件模型上，有天然的优势，但对于逻辑简单的业务和产品，或者非业务形态的应用，如内部 OA、BigData 等场景，DDD 并非最佳选择。

设计流程

首先第一步，根据业务诉求，提炼出整体的业务流程，同时拆解出里面的关键事件，角色，参与者等核心实例。整个拆解和梳理的方法论，目前业界有一些比较成熟的，比如事件风暴，四色建模法等。

提炼完整个业务流程后，进入战略设计阶段，这个阶段主要是从全局和顶层的视角，把整个业务语义转换为结构化分层。通过领域和子域的划分，同时结合通用域、支撑域、限界上下文等设计，分解问题复杂度，也就是前面说到的“分而治之”的思想。

接下来就会到具体的战术设计阶段，通过前面的战略设计阶段，已经把整个领域、边界、上下文等关键模块都梳理完成，现在就是从各个域中再次拆解更细粒度的模块，去指导最终的编码实现，这些更细粒度的模块包括实体、聚合、聚合根等。

最后就到了编码实现阶段，DDD有一个关键价值，叫做“设计即实现”，所以在战术阶段的设计，理论上是可以直接作用于代码的分层结构，如果架构和战术阶段有出入，说明之前的设计有问题，可以复盘重新推演。

基础概念

在DDD中分为战略设计和战术设计：

• 战略设计主要面向业务，进行分析拆解，为业务系统的设计打下基础
• 战术设计更多的是面向技术，在战略设计的基础上，具体设计系统实现

战略设计

战略设计指的是对整个领域进行分析和规划，确定领域中的概念、业务规则和领域边界等基础性问题。在战略设计中，需要对领域进行全面的了解、分析、拆解，探究业务的规则和本质，并且需要考虑到领域的未来发展趋势和可能的变化。

领域

领域，Domain，是一个团队所要做的业务全集，这是一个面向业务的概念，处在某个业务团队里，你们要做的事就是这个团队的领域。

子域

子域，Sub Domain，是在领域这个整体下，划分出来的业务子领域，每个子领域有各自的业务概念、规则、流程，这些子域互相独立，但又相互关联。

根据在领域中的重要程度，分为：

• 核心域：决定业务核心竞争力的子域，如业务交易、订单
• 通用域：具有通用功能，被多个子域使用，如登录、权限
• 支撑域：支撑其它领域，具有业务特性，但又不通用，如某某业务的基础数据

限界上下文

Bounded Context，是业务边界的划分，可以是一个子域或多个子域的集合，通常划分的依据是：一个限界上下文必须支持一个完整的业务流程，保证这个业务流程所涉及的领域都在一个限界上下文中。例如业务的售前流程，对应的限界上下文要能支持用户完整地浏览、下单。

限界上下文一般是微服务拆分的依据，即每个限界上下文对应一个微服务。

战术设计

战术设计则是在战略设计的基础上，对领域中的具体问题进行具体的解决方案设计。关注的是领域中的具体情境和场景，需要针对具体的问题进行具体的分析和设计，以满足业务需求。

实体

实体是拥有唯一标识和状态，且具有生命周期的业务对象，通常代表现实世界中的某个概念，可以是名词，也可以是动作。

根据数据和业务逻辑在对象中封装程度的不同，实体有四种类型:

1. 失血模型：仅包含属性，连基本的 getter/setter 都没有，或者完全由框架动态生成，所有操作都通过外部工具类、DAO 或反射完成，如某些 ORM 的代理对象
2. 贫血模型：数据和行为分离，模型仅包含属性和简单的 getter/setter，几乎没有业务逻辑，业务逻辑都通过领域服务（Service）来完成，如 Java 中的 POJO
3. 充血模型：领域对象不仅包含数据，还封装了与自身相关的业务逻辑和行为，能主动响应业务操作
4. 胀血模型：领域对象承担了过多职责，不仅包含自身业务逻辑，还混入不属于它自身的业务逻辑、跨领域逻辑，甚至基础设施逻辑。

DDD 推荐使用充血模型，实际开发也常用贫血模型+复杂的领域服务来构建业务逻辑。失血模型一般只有和底层 DB 进行映射才会使用，而涨血模型是一种 anti-pattern，会导致对象臃肿、难以测试、违反单一职责原则 (SRP)。

值对象

通过对象属性值来识别的对象，它将多个相关属性组合为一个概念整体，用来描述领域的特定方面。值对象没有唯一标识（和实体的核心区别），没有生命周期，不可修改，当值对象发生改变时只能替换，如果值对象的所有属性都相同，那么就认为是同一个值对象。典型的例如字符串、整型、枚举等。

聚合

聚合是一组领域对象的集合，作为一个整体，可以看作是一个修改数据的单元，通常包含一个或多个实体和值对象。聚合内的所有对象要么全部成功保存，要么全部不保存，以此来保证数据的一致性。

聚合根，是聚合中的一个特定实体，它是外部对象唯一可以持有的引用。聚合外部的对象只能通过聚合根来访问或修改聚合内部的状态和对象。

聚合根可以理解成聚合根是若干对象的管理器，统筹这些对象所反映的业务实体。举个例子，订单通常可以作为一个聚合根，它聚合了下单的用户、订单价格、订单内容等实体，订单决定了整个聚合的状态和行为，并且是外部对象与聚合交互的唯一途径，外部只能通过聚合内部唯一的 id 如订单号来操作订单。识别聚合，通常可以通过 1-对象是否有独立存在的意义，不依赖其它对象的存在才有意义；2-可以被独立访问；这两点来判断。

领域、子域、限界上下文、聚合都是用来表示一个业务范围，领域、子域、限界上下文属于战略设计，而聚合属于战术设计，聚合的范围是小于前三者的。

领域服务

有些领域中的动作看上去并不属于任何对象。它们代表了领域中的一个重要的行为，不能忽略它们或者简单地把它们合并到某个实体或者值对象中。当这样的行为从领域中被识别出来时，推荐的实践方式是将它声明成一个服务，这个服务就是领域服务。

领域服务是无状态的，只有行为，它的存在是为了协调领域对象共同完成某个操作，换句话说，领域对象聚焦个体，领域服务聚焦整体。与此同时，领域服务还可以避免领域逻辑泄露到应用层。例如业务系统常用的各种 Service 就是领域服务的实践。

领域事件

领域事件是发生在领域中且值得注意的事件。而领域事件通常意味着领域对象状态的改变。领域事件在系统中起到了传递消息、触发其他动作的作用，是解耦领域模型的重要手段之一。我们往往利用消息队列来传递领域事件。

工厂和资源库

DDD 还涉及了两种设计模式：

1. 工厂模式：将创建复杂对象和聚合的职责分配给一个单独的对象，该对象本身并不承担领域模型中的职责，但是依然是领域设计的一部分。
2. 资源库模式（仓储 Repository）：用于封装数据访问逻辑，将底层数据存储进行抽象，提供对数据的持久化和查询。旨在将数据访问细节与领域模型分离，使领域模型更加独立和可测试，例如 MyBatis 的 Mapper。

领域建模

事件风暴建模

事件建模法是一种元方法，底层逻辑是通过寻找事件，以及事件背后的领域概念，来完成对领域概念的挖掘和建模。

事件风暴（Event Storming）是事件建模的一种实践方式，是一种轻量级、协作式的领域建模方法，最初由意大利软件顾问 Alberto Brandolini 在2013年提出。它主要用于快速探索和理解复杂业务领域，特别适用于领域驱动设计的上下文映射和模型构建。其核心目标是：

• 快速发现业务流程中的关键元素。
• 促进开发人员与领域专家之间的高效沟通。
• 可视化整个业务流程，识别问题和改进点。
• 为后续的软件系统设计（尤其是微服务架构）提供清晰的输入。

基本元素

事件风暴建模通常用不同颜色的便利贴表示（颜色不固定，只要团队内统一即可）：

元素	颜色（常见约定）	含义
领域事件（Domain Event）	橙色	系统中已经发生的重要事实，用过去时描述，如“订单已创建”、“支付已成功”。
命令（Command）	蓝色	触发领域事件的动作，通常由某个角色或系统发出，如“提交订单”、“发起支付”。
热点问题（HotSpot）	紫色	业务痛点，瓶颈，模糊点
角色/参与者（Actor）	黄色	执行命令的人或系统，如“客户”、“支付网关”。
外部系统（External System）	浅粉色	与当前系统交互的第三方服务。
策略/规则（Policy）	粉色	自动响应事件的业务规则，可触发新命令。
读模型（Read Model）	绿色	用以支撑决策的信息。通常与界面布局有关。

活动流程（头脑风暴）

1. 召集跨职能团队：包括开发人员、测试、产品经理、领域专家等。
2. 从领域事件开始：大家一起在墙上贴出业务过程中所有重要的“已发生事件”（橙色）。
3. 反向推导命令：问“是什么导致了这个事件？” → 贴出命令（蓝色）。
4. 标识谁发出命令：添加角色（黄色）或外部系统（浅色）。
5. 划定聚合边界：确定哪些命令和事件属于同一个聚合
6. 识别策略和读模型：补充自动行为和查询需求。
7. 梳理流程、发现瓶颈或不一致：讨论并优化业务逻辑。

特点

优点：

• 低技术门槛：只需便利贴和一面墙，无需工具。
• 高度协作：打破技术与业务之间的隔阂。
• 快速反馈：几小时内就能获得对复杂领域的初步共识模型。
• 支持DDD落地：自然引出限界上下文（Bounded Context）、聚合等概念。

问题：

• 模式偏重，需要不同角色的成员集体参与，涉及的人员多、流程长
• 发散阶段，所有参与者可以天马行空，但在产生有效信息的同时，也会产生大量的噪音，需要主持人收敛逻辑，因此事件风暴法极度依赖主持人的经验与判断，最终结果自然就会存在一定的随意性

应用场景

• 新项目启动前的业务探索。
• 现有系统重构或微服务拆分。
• 梳理混乱的遗留业务流程。
• 敏捷团队的需求分析与用户故事拆分。

四色建模法

四色建模法（Four-Color Modeling）是一种轻量级、面向对象的业务建模方法，由 Peter Coad、Eric Lefebvre 和 Jeff De Luca 在 1990 年代提出。它通过四种“原型”来描述现实世界的业务系统，帮助开发人员快速识别核心业务概念、建立清晰的对象模型。

用一句话来概括四色原型就是：一个什么什么样的人或组织或物品，以某种角色在某个时刻或某段时间内参与某个活动。 其中“什么什么样的”就是描述 DESC，“人或组织或物品”就是PPT，“角色”就是Role，而”某个时刻或某段时间内的某个活动"就是MI。

四种原型（颜色与含义）

颜色	原型名称	核心作用	典型例子
红色	关键时刻（Moment-Interval）	表示在时间轴上发生或持续的活动、事件或过程，具有业务意义。通常是系统要“记录”或“追踪”的核心。	订单、预约、销售、航班、会议、支付
黄色	角色（Role）	事件参与方在事件中扮演的角色	客户（在订单中）、员工（在排班中）、供应商（在采购中）
绿色	参与方/地点/事物（Party-Place-Thing）	系统中的基本实体，是角色的“载体”。它们本身不直接参与业务流程，但通过“扮演角色”参与。	张三（人）、北京仓库（地点）、iPhone 手机（物品）
蓝色	描述/规格（Description）	对上述对象的描述性信息	商品品类、产品型号、服务套餐、职位类型

四色之间的关系（建模规则）

1. PPT → 扮演 → Role
   • 例如：“张三”（PPT）在“订单#123”中扮演“客户”（Role）。
2. Role → 参与 → Moment-Interval
   • 例如：“客户”（Role）参与了“下单”这个 Moment-Interval。
3. Description → 描述 → PPT 或 Moment-Interval
   • 例如：“iPhone 15 Pro”（Description）描述了多个具体的手机设备（PPT）；
     “标准配送服务”（Description）描述了多个配送事件（Moment-Interval）。

四色建模 vs 事件风暴

维度	四色建模	事件风暴
起源	1990s，面向对象分析（OOA）	2013，领域驱动设计（DDD）
核心焦点	静态对象模型（谁、什么、角色、事件）	动态业务流程（事件流、命令、聚合）
输出形式	类图、对象关系	时间线上的事件流 + 聚合边界
适用阶段	需求早期、概念建模	领域探索、微服务划分
是否强调时间	是（Moment-Interval 本质是时间相关）	是（事件是过去发生的）
协作方式	分析师主导，可协作	高度协作式工作坊

💡 两者可以互补：先用事件风暴梳理流程，再用四色建模提炼对象结构。

特点

优点：

• 简单直观，非技术人员也能理解。
• 避免过早陷入技术细节，聚焦业务本质。
• 有效防止“贫血模型”（只有属性没有行为）。
• 支持高内聚、低耦合的对象设计。

注意点：

• 不是所有系统都严格符合四色，但大多数业务系统能映射到这四类。
• 它是一种分析模式，不是数据库设计规范，后续仍需转换为具体实现。
• 在 DDD 中，Moment-Interval 常对应聚合根，尤其是那些有生命周期的业务过程。

总结

DDD 是一种软件架构设计方法，直接面向业务的软件工程指导思想，究其本质，还是为了应对软件的高复杂度，实现高内聚、低耦合的一个工具，而并非银弹。因此在实战中需要结合实际业务理解学习其思想。

参考文档

1. https://zhuanlan.zhihu.com/p/641295531
2. https://www.woshipm.com/share/6058576.html