3

在我的公司，我们目前使用 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 像域模型一样，直接处理命令，而不是通过模型发送命令并处理结果事件。这是处理此类案件的正确方法吗？还有其他更有效的方式在上下文之间进行通信吗？

4

1 回答 1

2

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

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

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

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

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

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

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

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

于 2013-02-07T17:51:15.653 回答