domain-driven-design - 将新的 BC 引入 DDD 应用程序的最佳实践是什么？

Question

这是一个关于在我们使用 ES 和 CQRS 以及 DDD 的系统中引入新 BC 的理论问题。所以不会有具体的例子。

引入新的 BC-s 可能会产生有趣的问题，新的 BC-s 通过接收和发布域事件与旧的 BC-s 进行通信。这些问题的根源在于我们在事件存储中已经有了领域事件。当新的 BC 对那些旧的域事件使用react时，它将以不同步和/或不按顺序的方式进行。

例如，我们有一个旧的 BC A，我们引入了一个新的 BC B。两者都发布领域事件，我们称之为 a 和 b。在新系统中，顺序很重要，例如 b1 必须始终在 a1 之后，但在 a2 之前。当事件存储中已经有了 a1、a2、a3 序列时，我们该怎么办？我们应该在 a1 之后注入(inject) b1 等等吗？这是一个巨大的事件存储的可行解决方案吗？将所有旧事件逐一重播并使用react肯定需要很长时间。我们如何通过处理新创建的 b1 事件来防止向客户发送电子邮件，该事件对 5 年前的主题使用react？有没有一种模式可以防止这类问题？

Answer 1

问题分析

The root of these problems that we already have domain events in the event storage.

如果您将新的 BC B 引入现有系统，这意味着系统在没有 B 的情况下也能正常运行。上述声明清楚地表明了这一点，并具有以下后果:

• B 本应响应来自 A 的事件而产生的事件不需要发布。没有其他系统应该根据这些事件采取行动，因为它们是人为的。
• 您可以随时选择使用 B 进行直播。您事先唯一需要做的就是让 B 与系统的当前状态同步。

让 B 同步

如果您相应地设计B，这并不困难。

1. 首先，您需要一个重播模式机制来将所有域事件导入B ，而不是从B 发布事件作为响应。 如果您使用事件源，您当然需要在内部保留 B 的事件，但不要发布它们。另外，请确保 B 不会通过其他方式在重播模式下修改世界状态，例如不要发送电子邮件。
2. 然后，将B 切换到实时模式。现在 B 使用系统中的新事件并发布自己的事件。

您提到的事件排序问题仅在您对所有域事件使用统一事件存储并且还使用该存储从中发布事件时才会出现问题。如果是这种情况，那么您需要在重放阶段将 B 的事件标记为“内部”，并将它们从发布机制中隐藏起来。

注意:如果 B 是一个纯粹的响应式 BC(这可能是一个非常简单的 BC 的情况)，那么您甚至不需要重放的东西。但大多数 BC 可能会这样做。