领域驱动设计 (DDD)：领域模型粒度和有界上下文

Question

下午

我目前正在学习领域驱动设计 (DDD)，但无法掌握基本概念。

Patterns Principles and Practices (Millett and Tune)

在我的学习过程中，我经常遇到域模型 (DM) 这个术语，但它通常以不同的粒度级别进行讨论。

1. 在某些情况下，它表示为各种相互关联的对象（客户、销售、报价、发票等）的工件（UML、草图、照片）的集合，这些对象概述了单个子域中的所有概念。

   使得单个子域只有一个模型

2. 在其他情况下，它表示为单个实体，例如 Product，其中一个子域将由许多不同的域模型组成。

由于上述模棱两可，我很难理解领域模型实际上是什么以及如何将这些模型放入有界上下文 (BC)

除此之外，我已经阅读了域模型可以在不同的限界上下文之间共享。

例如 Employee 在 Payroll 和 HR 有界上下文

之间共享

考虑到这一点，

1. 我要创建多个域模型来代表一个子域吗？
2. 还是只有一个？
3. 如果是后者，如何在上下文之间共享如此大的模型？

请有人能阐明这种歧义并准确解释什么是领域模型以及它的粒度。

非常感谢

丹尼尔

Answer 1

请务必查看The Blue Book。

究竟什么是领域模型...

领域模型是

• 企业关心的数据/状态/信息的集合
• 管理数据如何更改的规则

读取领域模型可以在不同的限界上下文之间共享

也许……

员工在工资单和人力资源有界上下文之间共享

在您的设计中包含一件重要的事情：当您跨越一个上下文和另一个上下文之间的边界时，无处不在的语言会发生变化。如果 Payroll 和 HR 不以相同的方式理解 Employee，使用相同的规则来管理数据的更改和相同的生命周期，那么坚持他们共享相同的模型会使您面临如果这些模型不会面临的风险分开存放。

更复杂的事情是了解您的模型是否是“记录簿”。例如，员工——如果你在谈论人类——就在现实世界中。现实世界是记录簿；您在数据库中捕获的信息只是一个副本。

例如：在现实世界中，人们在法律上有权更改自己的姓名。这对您的业务意味着什么？这种影响的时间对 HR 流程的影响是否与对薪资流程的影响相同？如果它们今天是一样的，你确定这将永远是真的吗？

在成为员工之前，该人可能是申请人； HR在乎吗？有工资吗？

还有一些实际问题——如果 HR 数据库出现故障，是否会阻止工资单处理？

Answer 2

Patterns Principles and Practices (Millett and Tune) 是一本非常好的 DDD 书籍，解释清晰。

使用 DDD 的战略模式，将应用程序分解为子域；其中每个子域代表问题域的不同部分。复杂的子域可以包含多个模型，一个模型也可以跨越多个子域。

因此，明确定义模型的边界以保护其完整性非常重要。这是通过将模型绑定到其特定上下文（称为有界上下文）来实现的。每个有界上下文都有一个域模型。

领域模型代表问题空间，是根据开发团队和业务团队之间的讨论得出的。它基于普遍存在的语言，并使用草图和 UML 图表示。您的代码模型中也有同样的反映。

除此之外，我还阅读了 Domain Models can be shared between different Bounded Context。

例如 Employee 在 Payroll 和 HR 有界上下文

之间共享

考虑到这一点，

我会创建多个域模型来代表一个子域吗？ 还是只有一个？ 如果是后者，如何在上下文之间共享如此大的模型？

这是 Shared Kernel 模式的一个例子，其中两个有界上下文共享相同域逻辑的子集。您将需要创建 3 个域模型，一个用于 Employee 和 HR，一个用于共享模型 Employee