有界上下文共享相同的聚合

Question

DDD公开有界上下文，域模型，聚合......但我经常错过业务规则的关键点。我想知道业务规则如何融入这种方法。这是一个例子：

想象一下，您在信贷公司中拥有2个有界的背景。一个用于债务追偿，另一个用于提前退款。这些背景嵌入了真实的业务特征。从概念的角度来看，我认为这些有界的上下文应该分别嵌入共同的模型部分和类似的领域模型实体（3或4个会计实体的图形）。即使他们各自的模型嵌入了一个共同的子模型（我们不计划它可以改变），适用于这些子模型的业务规则也是不同的。 DebtRecoveryService确保正确应用规则，另一个EarlyFundsService使用特定的会计规则执行相同的操作。

• 这个子模型是否应该被嵌入并且＆＃34;服务于其他人＆＃34;如果不同的业务规则适用于他们（在数学和各自的行为方面？），则通过另一个专门的有限上下文。
• 什么定义了聚合，它只是模型的一部分？
• 特定的业务规则是否定义了特定的聚合？

您认为聚合应该只考虑它所代表的实体图，并且可以重复使用＆＃34;通过其他有界的背景。这是CQRS的好例子吗？

谢谢，

Answer 1

很明显，根据DDD，你应该复制模型，当它们被不同的有界域共享时。

此外，服务模式鼓励不在服务的两端使用相同的对象。

然而。如果您正在使用POCO样式的数据对象并将业务逻辑封装在服务中而不是经典的OO对象图方法中，那么您必须采用多种模式来保护自己免受同一问题的影响。

在这种情况下，如果该模型的域意义随着时间的推移在有限的上下文之间分离，那么拥有共享通用模型的代码重用的好处可能会超过潜在的技术债务。

虽然这可能发生在有限的上下文中。我觉得你的问题可以归结为＆＃34;我选择了正确的有界背景吗？＆＃34;这当然是主观的。

Answer 2

一个基本规则是，只有当某些域逻辑似乎不适合任何实体时，才应使用域服务。域服务不是指有限的特定于上下文的“看门狗”来控制对共享哑数据结构所做的更改。

如果域不变量可以包含在聚合中，那么肯定将它们放在那里 - 在两个BC中有两个具有相似数据但规则不同的聚合是正常的，这就是为什么你首先有有界上下文的原因。

作为旁注，有界背景设计不是你应该即兴创作的。我强烈建议阅读原版蓝皮书中描述的战术和战略模式以及Vaughn Vernon的红皮书。

上下文映射或共享内核等模式仅举几例，是了解设计有界上下文时的有用工具。 BC设计不仅取决于业务问题，还取决于组织因素，例如哪些团队将维护环境，历史因素（遗留背景与绿地背景）等。

你将会在书中了解所有这些以及大量其他重要内容，这些内容有望消除你似乎所处的混乱。