领域驱动设计中的上下文之间的通信

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

在初始版本中，我们允许每个上下文接收事件 从任何其他上下文。然而，这很快就变得一团糟，因为它 变得很难跟踪哪些事件是在哪里处理的。

我认为仅此一项没有问题。 BC 之间通过事件进行通信是一种典型的事件驱动架构。事件的跟踪可以通过上下文映射来完成。

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

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

特别是在我们的客户网站上下文中，模型包含几乎 没有逻辑或状态，仅用于生成事件 非规范化到网站数据库。

这似乎是 CQRS 术语中的视图/投影。同样，这里没有错。

我们现在的一个想法是让我们的 CMS 像域模型一样工作，并且 直接处理命令而不是通过模型发送它们 处理结果事件。

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