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

Question

下午全部

我目前正在学习领域驱动设计(DDD)，并且很难掌握基本概念。

模式、原则和实践(米利特和曲调)

在我的研究中，我经常遇到术语Domain (DM)，但是它通常是用不同级别的粒度来讨论的。

1. 在某些情况下，它表示为各种相互关联的对象(客户、销售、报价、发票等)的工件(UML、草图、照片)的集合，其中概述了单个子域中的所有概念。 使得单个子域只有一个模型。
2. 在另一些情况下，它表示为单个实体，如Product，因此子域将由许多不同的域模型组成。

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

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

例如，Employee在Payroll和HR有界上下文之间共享。

考虑到这一点，

1. 我会创建多个域模型来表示子域吗？
2. 还是就一个人？
3. 如果是后者，人们将如何在上下文之间共享如此大的模型？

请有人解释一下这个模棱两可的问题，并解释一下领域模型是什么，以及它能有多细。

非常感谢

丹尼尔

Answer 1

确保您查看蓝皮书。

领域模型是什么..。

域模型是

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

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

也许..。

员工在薪资和人力资源限制上下文之间共享。

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

更复杂的是了解你的模型是否是“记录簿”。举个例子，员工--如果你说的是人--就在现实世界里。现实世界是一本记录书，你在数据库中捕捉到的信息只是一份副本。

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

在成为员工之前，人可能是申请人；人力资源部关心吗？工资单吗？

还有一些实际问题-如果人力资源数据库出现故障，是否应该阻止薪资处理？