有界上下文共享同一聚合 [英] Bounded contexts sharing a same aggregate

问题描述

DDD公开了有限的上下文，域模型，聚合...但是我经常错过业务规则的要点。我想知道业务规则如何整合到这种方法中。这是一个示例：

DDD exposes bounded contexts, domain models, aggregates... but I often miss the keypoint of business rules. I would like to know how business rules integrate into this approach. Here is an example :

假设您在一家信贷公司中有2个有界上下文。一个用于债务追回，另一个用于早期退款。这些环境嵌入了实际的业务特性。从概念的角度来看，我认为这些有界上下文应分别嵌入通用模型部分和相似的域模型实体（3个或4个会计实体的图）。即使它们各自的模型都嵌入了一个公共子模型（我们不计划它可以更改），但应用于这些子模型的业务规则却有所不同。 DebtRecoveryService确保规则正确应用，而另一个EarlyFundsService使用特定的会计规则执行相同的操作。

Imagine you have 2 bounded contexts in a credit company. One for debt recovery, the other for early refunds. These contexts embed real business specificities. In a conceptual point of view, I think these bounded contexts should separately embed common model parts, and similar domain model entities (graph of 3 or 4 accountancy entities). Even if their respective models embed a common submodel (we do not plan it can change), business rules that apply to these submodels are different. A DebtRecoveryService ensures rules are correctly applied, and another EarlyFundsService does the same, with specific accountancy rules.

• 如果子模型适用于不同的业务规则，则该子模型是否应由另一个专用的有界上下文嵌入并提供给其他人


• 什么定义了聚合，仅仅是模型的一部分？


• 特定的业务规则是否定义了特定的聚合？

您是否认为聚合应该仅针对其表示的实体图考虑，并由其他边界重用上下文。

谢谢，

推荐答案

很显然，根据DDD，当您由不同的有界域共享模型时，应该 复制您的模型。

It seems pretty clear that according to DDD you should duplicate you models when they are shared by different bounded domains.

也可以提供服务模式鼓励不要在服务的两端使用同一对象。

Also service patterns encourage not using the same object on both sides of the service.

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

However. If you are using POCO style data objects and encapsulating business logic in services rather than the classic OO object graph approach, you are essentialy employing multiple patterns to protect yourself from the same issue.

在这种情况下，如果模型的域含义在有限的上下文之间漂移，那么拥有一个共享的通用模型所带来的代码重用的好处可能会超过潜在的技术债务。时间。

In this case the benefits of code reuse from having a shared common model could out-weigh the potential tech debt should the domain meaning of that model drift apart between bounded contexts over time.

本质，尽管在有限的上下文中可能会发生这种情况。我觉得您的问题可以归结为我是否选择了正确的有界上下文？当然是主观的。

Essentialy though this could happen with in a bounded context. I feel your question could boil down to "Have I chosen the correct bounded contexts?" which of course is subjective.

这篇关于有界上下文共享同一聚合的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！