下午好
我目前正在学习领域驱动设计 (DDD)，但在掌握基本概念时遇到困难。
Patterns Principles and Practices (Millett and Tune)
在我的学习过程中，我经常遇到术语域模型 (DM)，但通常会以不同的粒度级别对其进行讨论。
在某些情况下，它表示为各种互连对象(客户、销售、报价、发票等)的工件(UML、草图、照片)集合，概述了单个子域内的所有概念。
这样单个子域只有一个模型
在其他情况下，它表示为单个实体，例如产品，其中子域将由许多不同的域模型组成。
由于上述歧义，我很难理解域模型实际上是什么以及如何将此类模型放入有界上下文(BC)
除此之外，我还阅读了域模型可以在不同的有界上下文之间共享。
例如，员工在薪资和HR限界上下文之间共享
考虑到这一点，
- 我会创建多个域模型来表示一个子域吗？
- 还是只有一个？
- 如果是后者，如何在上下文之间共享如此大的模型？
请有人阐明这种歧义，并准确解释什么是领域模型以及它的粒度。
非常感谢
丹尼尔
最佳答案
请务必查看The Blue Book .
exactly what a Domain Model is ...
域模型是
- 企业关心的数据/状态/信息的集合
- 控制数据如何更改的规则
read Domain Models can be shared between different Bounded Context
也许...
Employee is shared between the Payroll and HR Bounded Context
设计中要包含的一件重要事情是:当您跨越一个上下文和另一个上下文之间的边界时，无处不在的语言会发生变化。如果薪资和人力资源部门不以相同的方式理解员工，不使用相同的规则来管理数据的更改和相同的生命周期，那么坚持他们共享相同的模型会让您面临如果这些模型不适用则不会面临的风险分开保存。
让事情变得更加复杂的是了解您的模型是否是“记录簿”。例如，员工——如果你谈论的是人类——就在现实世界中。现实世界是一本记录本；您在数据库中捕获的信息只是一个副本。
例如:在现实世界中，人们依法有权更改自己的姓名。这对您的业务意味着什么？这种影响的时间对人力资源流程的影响是否与对薪资流程的影响相同？如果它们今天是一样的，您确定这将永远如此吗？
在成为雇员之前，该人可能是申请人； HR关心吗？有工资吗？
还有一些实际问题 - 如果 HR 数据库出现故障，是否会阻止薪资处理？
关于domain-driven-design - 领域驱动设计(DDD): Domain Model Granularity and Bounded Context，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/37488241/