Domain driven design 领域驱动设计（DDD）：领域模型粒度和有界上下文

下午好

我目前正在学习领域驱动设计（DDD），很难掌握基本概念

在我的研究中，我经常遇到术语领域模型（DM），但它通常以不同的粒度级别进行讨论

在某些情况下，其表示为各种互连对象（客户、销售、报价、发票等）的工件（UML、草图、照片）的集合，这些工件概述了单个子域中的所有概念

这样，单个子域只有一个模型

在其他情况下，其表示为单个实体，例如产品，其中子域将由许多不同的域模型组成

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

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

例如，员工在工资和人力资源范围内共享

有鉴于此,

我会创建多个域模型来表示一个子域吗

还是只有一个

如果是后者，如何在上下文之间共享如此大的模型

请有人解释一下这种模糊性，解释一下域模型到底是什么，以及它的粒度有多大

非常感谢

丹尼尔

一定要复习

域模型到底是什么

域模型是

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

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

也许

员工在工资单和人力资源上下文中共享

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

更复杂的是要了解你的模型是否是“记录簿”。例如，员工——如果你说的是人——就在现实世界中。现实世界是一本记录在案的书；您在数据库中捕获的信息只是一个副本

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

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

还有一些实际问题——如果人力资源数据库出现故障，是否会阻碍工资单处理？

是一本关于DDD的非常好的书，有着清晰的解释

使用DDD的策略模式，将应用程序分解为子域；其中每个子域代表问题域的一个不同部分。复杂子域可以包含多个模型，一个模型也可以跨越多个子域

因此，明确定义模型的边界以保护其完整性是很重要的。这是通过将模型绑定到其特定上下文（称为有界上下文）来实现的。每个有界上下文都有一个域模型

领域模型表示问题空间，并基于开发团队和业务团队之间的讨论得出。它基于通用语言，并使用草图和UML图表示。同样的情况也会反映在您的代码模型中

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

例如，员工在工资单和人力资源上下文之间共享

有鉴于此,

我会创建多个域模型来表示一个子域吗？ 还是只有一个？ 如果是后者，如何在上下文之间共享如此大的模型

---

这是一种共享内核模式，其中两个有界上下文共享同一域逻辑的子集。您将需要创建3个域模型，一个用于员工和人力资源，一个用于共享模型员工

域模型存在于有限的上下文中，并且通常应与子域1-1对齐。感谢@plalx深入的反馈，域模型用于表示单个对象，如“客户”或者它是子域中存在的所有对象的集合？模型是一个重载术语。它可以是1或1。或2。取决于上下文。当谈到DDD、子域和有界上下文时，它往往是1。不过，非常感谢，这确实让我更清楚了。从实际的角度来看，我的说法是正确的：给定一个子领域的销售。我将创建多个域模型，表示不同的概念，如票证、用户、资产，它们表示“企业关心的数据/状态/信息”。因此，用户模型可能在同一子域内的不同上下文之间共享，也可能不共享？@DanielKaizer Yo弄错了。Sales子域表示域中与销售相关的问题，但未定义解决方案。解决方案可以由一个销售范围有限的上下文组成，其核心是一个域模型。客户、产品等概念可能是该领域模型的一部分，但它们不是领域模型，而是聚合根、实体、值等。给予