迄今为止最通俗易懂的 DDD 落地实战_AI阅读总结 — 包阅AI

本文以餐厅场景为叙事主线，以领域驱动为核心思想，结合架构设计与功能设计方法论。是从领域分析到落地的全过程案例，内容偏重于落地，因此不乏一些探讨，欢迎指正。

文章较长、全程干货、耐心读完、必有收获。

本文不针对餐厅的实现细节，重在探讨设计思想和方法。

让我们抛开技术人员的本能技术视角、站在纯业务视角来分析领域问题。

领域设计的核心是分而治之，目的是实现业务领域的自治性。

就像你平时不会将枕头和被子放在厨房或卫生间一样，你的床上不会放着大米白面，否则你想睡觉是一件很复杂的事情，软件系统也是如此，这就是我们要解决的问题。

假如我要设计一个餐厅，由于分而治之的需要，我会首先从宏观流程去分析，可以帮我们迅速找到重要的区域。

因此会得到几个明确的行为区域，我将餐厅划分为“菜品域”，“订单域”，“厨房域”，“用餐域”，这是业务级别的领域划分，后续应该针对每个区域单独分析。

产出物是：宏观流程和参与角色

语言贯穿于整个开发过程，从需求分析到设计、从设计到编码，因此好的语言非常重要，好的语言体现了清晰的业务概念。

在这个阶段，我们需要通过梳理，找到业务中都有哪些实体与行为，对其做一些归纳。我们的核心问题是：“谁”通过什么“行为”影响了“谁”，其中的三个要素分别是：角色、行为、实体。我的建议是先找到 “角色”、“实体”、“行为”，并对其归类，我常常关注角色以及具体身份、实体以及实体实例，功能以及包含的重要步骤。

推荐使用脑图画出来，我认为归纳后的脑图有助于我们识别根本要素，有利于抽象。

产出物是：名词、概念定义、相关脑图

在这一步、我们使用相对宏观的分析，不需要进入用例的细节分析，掌握角色与行为之间的关系，理清谁在做什么，角色的职责差异是什么。

产出物：用例图

以做菜为例，如图：

我们在分析宏观流程时，划分了几个行为区域，但那是业务级别的。在那基础之上，我们需要拉进某个区域的视角，再结合之前的用例分析，按照“功能相关性”、“角色相关性”进一步划分领域。

通常来说，子域不具备独立的问题空间，不会作为独立的领域存在。

产出物：领域、子域

以厨房域为例，如图：

这是大家比较熟知的阶段，重点分析实体与领域之间关系（领域聚合），实体与实体的关系（OO聚合）。

领域模型是实现功能的基石、需要有对功能的本质理解，才能找到最核心的实体，实体之间的OO聚合关系决定了功能的扩展性，OO聚合是最重要的核心点。

组合、聚合

可以使用如下案例，既能表达领域聚合，又能表达OO聚合的关系。

产出物：聚合、实体、值对象、实体的属性

（领域服务和事件在后续的功能设计中提供）

领域上下游关系，不是领域的依赖关系，依赖关系指的是能力的依赖，是共用了某些能力，依赖关系是固定的。领域上下游关系，也不是调用关系，调用关系是与用例相关的，并非描述领域处境的。

领域上下游关系指的是影响力的关系，上游影响下游，影响力分为“逻辑影响”和“数据影响”，一般说来我们更应该关注“数据影响”，所以领域上下游关系是一种数据流向的限定，是业务发生的顺序限定，用于规定该领域所使用的数据，是下游领域依赖上游领域“准备就绪”的体现。合理的上下游限定，有助于减少领域之间的不必要依赖，有利于数据的复用并减少重复计算。

领域上下游是与场景相关的，并不是一成不变的，不同的场景存在不同的上下游，各场景应该独立说明。

产出物：各场景的上下游说明

如果厨房的某些食材不足了，或者某个厨师休假了，就会影响到菜品的展示，从而影响到客户的订单。

客户的订单、影响厨房生产的菜，从而影响刀工的行为，也影响到了采购。

请对比下面两个图，用于理解领域的上下游：

实际上，厨师不应该依赖采购人员的采购功能，也不依赖刀工的切菜功能，他只是依赖“初加工食材”而已，而“初加工食材”就是被处理好的数据，厨师在做饭时，“初加工食材”就已经被处理好了，上面的图例只是为了说明一个关于领域上下游的问题，这是业务发生顺序以及数据来源的问题。

我们常常使用领域事件串联业务流程，在使用领域事件时，不止要关注点对点的解耦，更应该使业务流程符合领域上下游限定，让各个领域独立运行，减少领域之间的功能依赖，降低领域之间的耦合，减少业务变化带来的影响。

架构设计是为了解决软件系统复杂度带来的问题，找到系统中的元素并搞清楚他们之间关系。

架构的目标是用于管理复杂性、易变性和不确定性，以确保在长期的系统演化过程中，一部分架构的变化不会对其它部分产生不必要的负面影响。这样做可以确保业务和研发效率的敏捷，让应用的易变部分能够频繁地变化，对应用的其它部分的影响尽可能小。

架构设计三原则：合适原则、简单原则、演化原则

我们需要按照 接口层、领域层（领域用例层、领域模型层）、依赖层、基础层 构建架构模型。

架构的视角，从大到小依次是：系统->应用（微服务）->模块（包）->子模块 这样的从大到小的层级。

领域设计，类似餐厅设计师，他设计餐厅有几个区域，区域的用途是什么。

架构设计，类似建筑设计师，他设计如何走水电煤气、如何施工等。

产出物：分层架构图

以厨房为视角，其架构如下：

以餐厅为视角，其架构如下：

分层架构图，体现逻辑上的层级分布，而不是代表组件的具体含义，组件是应用还是模块、需要结合实际情况而定。

1）分层架构越往下层就越是稳定的

下层是被上层依赖的，下层不可以反向依赖上层（扩展点除外）。因为分层架构的核心原则是将容易变化的逻辑上浮，将共性的、原子化的、通用的逻辑下沉，被依赖的下层应该是稳定的，这要求上层承接更多业务变化。下层离开上层应该是可以独立存在的，例如在接口层定义的DTO不可以在下层被使用，但领域层定义的实体可以被上层使用。

2）在使用充血模型时，应该符合面向对象编程原则

不要随意将一些能力都充到领域实体模型中。以“菜”为例，重量和规格是“菜”的自身的属性，激发味蕾是“菜”的能力，“菜”可以维护自身的持久化状态。但是、请注意、“菜”不可以“炒菜”，因为“炒菜”的时候，“菜”还没有出现呢，“菜”不是自己的上帝，“菜”需要被做出来，所以“菜”被做出来之前是没有“菜”的，这是个时间上的概念，不要错把“炒菜”的能力放在“菜”的身上。“炒菜”用到的“水+电+气+食材+调料+厨具”不应该是“菜”的属性范围，这些元素都在“厨房”的范围中，不要让领域的模型包含不属于自身的元素，领域的实体模型只是领域的一部分，只用于实现通用的模型能力。

3）接口层和依赖层是与领域无关的

他们是与技术相关的层级，不属于任何领域，这两层不能包含业务逻辑。有时候我们可以把接口层拆为两层（接口层+应用层），也可以把依赖层拆分为两个（模型依赖、服务依赖）。

4）领域层是与环境无关的

无论某个领域是应用还是模块，都应该具备独立的用例层和独立的模型层，即使多个领域在同一个应用当中，也要按照他们是分别独立的去看待，无论某个领域是应用还是模块，领域对外部的交互，不可以绕过依赖层和接口层。

5）领域应该是最小完备的

把一个领域拆分为子域、子子域、子子子…… 无限拆分，拆分到一定程度之后，某个子域就不完整了，不完整的子域是不可以独立存在的。拆分不够或者过度拆分，都是不符合低耦合高内聚原则的。当一个领域的内部子域不具备独立性时，他们之间不必严格解耦，不需要通过依赖层访问本领域的其他子域，他们之间可以直接调用。

6）领域服务层就是领域用例层

他们俩是同一回事儿，都是用于实现领域内的用例的。不要将领域服务与领域用例视为两个独立的层，也不要将领域服务与领域模型视为同一层，否则会导致逻辑的分散（一部分在领域服务层、一部分在领域模型层、还有一部分可能在用例层），也会导致每个层的职责不明确，容易搞乱。如果将业务逻辑写在领域模型中，会导致业务逻辑进一步下沉，业务逻辑的不确定性太大，是不适合下沉的，是违反分层架构原则的。领域模型对应的是实体、领域服务对应的是用例。

7）领域用例层只能承接符合自身领域的用例

我们划分出领域的目的，就是为了区分每个领域的职责所在，因此他们必须严格按照职责办事，我们在之前已明确了用例和领域之间的关系，需要严格遵守。

8）领域模型层遵循最小依赖原则

只可以依赖必要的资源，必要资源指的是领域模型实现自身能力需要的资源，不包括实现业务逻辑包含的资源。例如领域模型需要依赖DB完成持久化，可以依赖数据访问资源，但不应该依赖其他领域资源、不可以依赖RPC资源等。

服务划分以领域划分为参考，主要看我们要拆分到什么粒度，这 应该符合低耦合高内聚原则，不破坏领域实体的聚合关系。

产出物：微服务

所以餐厅被拆分为：厨房（Kitchen）、菜品（Category）、订单（Order）三个微服务。

基于此、我们单独拿出餐厅门面服务作为接口层应用，再单独拿出餐厅基础服务作为水电煤气的应用。

一般情况下，依赖层不会作为单独的服务提供，会被以组件的形式嵌入到其他服务中。

如果说领域设计是餐厅的设计师、架构设计是餐厅的建筑师、那么功能设计就是餐厅的厨师或服务员。

任何设计都要落地到功能设计，如果厨师不守规则，偏偏要去洗手间洗菜，最后的结果依然是一团乱，最终会导致设计无法落地。

功能设计是实现 “面向扩展开放、面向修改关闭” 的途径，是指导研发落地必备环节。

功能迭代时，功能会发生一些变化，所以它的含义是可能变化的，所以我们需要再次审视功能的概念，及时加以调整。

例如、我们实现了一个“做蛋炒饭”的功能，后来又实现了一个“做辣椒炒蛋”的功能，那么我们应该将功能升级为“炒菜”，甚至是“制作菜品”等。

明确功能的概念，是功能设计的前提。

产出物：更新语言库，更新脑图

我们在领域分析章节，已明确了用例与角色的关系，用例与领域的关系。

然而一个新功能的加入，我们仍然要再次评估，以确保他处于正确的位置。

产出物：更新用例图

我们需要深入功能的细节，首推的方法是事件风暴，适用于解构复杂功能。

事件风暴的作用并不限于功能分析，只是我觉得很适用于功能分析，事件风暴的一张图包含很多内容，正好是功能设计所需要的。

产出物：事件风暴模型

我们暂且收回思路，首先要关注共性和差异问题，以确保功能的扩展性。

确认用例的泛化+差异点，实现功能的扩展。

寻找共同包含的步骤，实现逻辑的复用。

产出物：用例分析图

例：制作菜品（做大拌菜、做铁锅炖、做炒鸡蛋、做蒸米饭、做炒米饭）

专注于用例层的类设计，实现“面相修改关闭，面相扩展开放”。

用例的类结构图是用例分析图的一种映射。

产出物：用例层的类结构图

我们接回思路，更进一步，将事件风暴模型落实到代码层面。

我们将步骤分配到实现类中、步骤就是该类的一个方法，进一步明确由哪个类和方法来实现该步骤，从而就规定了步骤所在的领域。

我们将步骤和领域事件串联起来，规定了业务实现流程。推荐使用泳道图表达上述内容。泳道的纵向组件是用例的实现类。

这是真实业务流程的映射。

产出物：用例流程图

以炒鸡蛋为例，其用例流程图如下：

我们进一步将事件风暴模型落实到代码层面，我们使用时序图，体现依赖和调用关系，规定了步骤与领域实体模型的关系，进一步说明用例是如何实现的。

这时候，为了简便、我们可以收起领域服务类（用例层）的泳道。

产出物：时序图、活动图

试想一下、假如把业务逻辑放在领域模型当中（例如聚合），如何实现“面相扩展开放、面相修改关闭”呢？

编码实现……我决定还是……偷个懒吧……哈哈哈。

但是我们回顾一下之前的内容，是否足够了？不同的研发人员依照设计去编码，是否会写出不一样的代码？

最后，我们的目标是“解决软件复杂度带来的问题”，而实现这个目标的途径是“设计指导研发落地”。