下午所有
我目前正在学习领域驱动设计(DDD)，很难掌握基本概念。
模式原理与实践(Millett and Tune)
在我的学习过程中，我经常遇到领域模型(DM)这个术语，但它通常以不同的粒度级别进行讨论。
-
在某些情况下，它表示为各种互连对象(客户、销售、报价、发票等)的工件集合(UML、草图、照片)，这些工件概述了单个子域内的所有概念。
使得单个子域只有一个模型
-
在其他情况下，它表示为单个实体，如Product，其中子域将由许多不同的域模型组成。
由于上述歧义，我很难理解领域模型到底是什么，以及如何将这些模型放入有界上下文(BC)
除此之外，我还阅读了领域模型可以在不同的有界上下文之间共享。
例如，员工在工资单和人力资源受限上下文之间共享
考虑到这一点，
- 我会创建多个域模型来表示子域吗
- 还是只有一个
- 如果是后者，如何在不同的上下文之间共享如此大的模型
请有人阐明这种模糊性，并准确解释什么是域模型以及它的粒度。
非常感谢
Daniel
一定要复习《蓝皮书》。
域模型究竟是什么。。。
域模型是
- 企业关心的数据/状态/信息的集合
- 控制数据如何更改的规则
read域模型可以在不同的有界上下文之间共享
也许。。。
员工在工资单和人力资源边界上下文之间共享
设计中需要包含的一件重要内容是：当您跨越一个上下文和另一个上下文之间的边界时，无处不在的语言会发生变化。如果Payroll和HR对Employee的理解不一样，对数据的更改有着相同的规则和相同的生命周期，那么坚持他们共享相同的模型会让你面临风险，如果这些模型分开，你就不会面临这些风险。
更为复杂的是了解你的模型是否是"记录之书"。例如，Employee——如果你谈论的是人——就在现实世界中。真实的世界是一本记录在案的书；您在数据库中捕获的信息只是一个副本。
例如：在现实世界中，人们在法律上有权更改自己的名字。这对你的生意意味着什么？这种影响的时机对人力资源流程的影响是否与对工资流程的影响相同？如果他们今天是一样的，你确定这将永远是真的吗？
在成为雇员之前，该人可能是申请人；人力资源部关心吗？工资单？
还有一些实际问题——如果人力资源数据库出现故障，是否应该阻止工资处理？
Patterns Principles and Practices(Millett and Tune)是一本关于DDD的非常好的书，有清晰的解释。
使用DDD的战略模式，应用程序被分解为子领域；其中每个子域表示问题域的不同部分。复杂子域可以包含多个模型，一个模型也可以跨越多个子域。
因此，明确定义模型的边界以保护其完整性是很重要的。这是通过将模型绑定到其特定上下文(称为有界上下文)来实现的。每个有界上下文都有一个域模型。
领域模型代表问题空间，是基于开发团队和业务团队之间的讨论得出的。它基于泛在语言，并使用草图和UML图来表示。同样的情况也会反映在代码模型中。
除此之外，我还阅读了可以在不同的有界上下文之间共享的域模型。
例如，员工在工资单和人力资源受限上下文之间共享
考虑到这一点，
我会创建多个域模型来表示一个子域吗？还是只有一个？如果是后者，如何在不同的上下文之间共享如此大的模型？
这是共享内核模式的一个例子，其中两个有界上下文共享同一域逻辑的子集。您需要创建3个域模型，一个用于Employee和HR，另一个用于共享模型Employee