c# - 域驱动设计中上下文之间的通信

Question

在我的公司，我们目前使用 DDD 架构，结合事件溯源和 CQRS。在初始版本中，我们允许每个上下文从任何其他上下文接收事件。然而，这很快就变得一团糟，因为很难跟踪哪些事件在何处处理。

我们目前的做法是只允许将命令发送到其他上下文。这样效果更好，但似乎会产生大量代码开销。例如:

context A sends a  command to context B, 
which changes the state of a domain model, 
which publishes an event, 
which gets handled by an event handler, 
which sends a command back to context A, 
which changes the state of a domain model, 
which publishes an event, 
which gets handled by an event handler,
which sends a command to context C,
etcetera.

不同上下文中的许多领域模型，以及触发命令发送到另一个上下文的许多事件，都包含大量相似的数据。特别是在我们的客户网站上下文中，模型几乎不包含任何逻辑或状态，仅用于生成可以反规范化到网站数据库的事件。它有效，但这似乎也不是可行的方法，因为发布事件不应该是任何域模型的唯一目的。

我们现在的想法之一是让我们的 CMS 像域模型一样运行，并直接处理命令，而不是通过模型发送它们并处理结果事件。这是处理此类案件的正确方法吗？还有其他更有效的方式来在上下文之间进行通信吗？

Answer 1

In the initial version, we allowed every context to receive the events from any other context. This however quickly became a mess, because it became very hard to track which events were handled where.

我不认为这有什么问题。 BC之间通过事件进行通信是典型的事件驱动架构。事件的跟踪可以通过上下文映射来完成。

然而，在您的案例中，BC 交互似乎变得过于健谈。这可能是次优边界的症状。也许边界太细了？鉴于多个域模型包含大量相似数据可能表明这些域应该合并。 BC 的基本原则是功能和语言的原则 cohesion - 密切相关的事物粘在一起。

域模型更改状态以响应命令然后发布事件是一个完全有效的工作流。

Especially in our customer website context, the models contain almost no logic or state and are just used to generate events which can be denormalized to the website database.

这看起来像是 CQRS 术语中的 View /投影。同样，这里没有问题。

One of our ideas now was to make our CMS act like a domain model, and handle commands directly instead of sending them through a model and process the resulting events.

这可能是一个重要的观察结果。在业务逻辑复杂的情况下，完整的领域模型才有意义。但是，如果域是 CMS 或 CRUD 的域那么就不需要领域模型了。但是，您仍然可以保留事件驱动架构的其余部分。