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