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