domain-driven-design - 微服务事件驱动架构的设计选择

Question

假设我们有以下内容:

DDD聚合了A和B，A可以引用B。

管理 A 的微服务公开以下命令:

创建一个

删除 A

链接 A 到 B

取消 A 与 B 的链接

管理 B 的微服务公开以下命令:

创建 B

删除 B

成功的创建、删除、链接或取消链接总是会导致执行该操作的微服务发出相应的事件。

为这两个微服务设计事件驱动架构的最佳方法是什么，以便:

A 和 B 最终将始终彼此一致。通过一致性，我的意思是如果 B 不存在，A 不应该引用 B。

来自两个微服务的事件可以轻松地转换到单独的读取模型中，在该模型上可以进行跨越 A 和 B 的查询

具体来说，以下示例可能会导致暂时的不一致状态，但最终必须在所有情况下恢复一致性:

示例 1

初始一致状态:A 存在，B 不存在，A 未链接到 B

命令:将 A 链接到 B

示例 2

初始一致状态:A 存在，B 存在，A 链接到 B

命令:删除 B

示例 3

初始一致状态:A 存在，B 存在，A 未链接到 B

两个同时执行的命令:将 A 链接到 B 并删除 B

我有两个解决方案。

解决方案 1

微服务 A 仅允许将 A 链接到 B，前提是它之前已收到“B 创建”事件且没有“B 删除”事件。

如果微服务 B 之前没有收到“A 链接到 B”事件，或者该事件之后是“A 与 B 取消链接”事件，则它只允许删除 B。

微服务 A 监听“B 已删除”事件，并在收到此类事件后，取消 A 与 B 的链接(对于 B 在收到链接到 B 事件的 A 之前删除的竞争条件)。

解决方案2:

微服务 A 始终允许将 A 链接到 B。

微服务 B 监听“A 链接到 B”事件，并在收到此类事件后验证 B 是否存在。如果没有，它会发出“链接到 B 被拒绝”事件。

微服务 A 监听“B 已删除”和“与 B 的链接被拒绝”事件，并在收到此类事件后将 A 与 B 取消链接。

编辑:解决方案 3，由纪尧姆提出:

如果微服务 A 之前没有收到“B 删除”事件，则它只允许将 A 链接到 B。

微服务 B 始终允许删除 B。

微服务 A 监听“B 已删除”事件，并在收到此类事件后，取消 A 与 B 的链接。

我看到的解决方案 2 的优点是微服务不需要跟踪其他服务发出的过去事件。在方案一中，基本上每个微服务都要维护另一个微服务的读模型。

解决方案 2 的一个潜在缺点可能是在读取模型中转换这些事件会增加复杂性，尤其是如果将更多遵循相同模式的微服务和聚合添加到系统中时。

一个或另一个解决方案是否还有其他(不利)优势，或者甚至是我不知道的反模式，应该不惜一切代价避免？
有没有比我提出的两个更好的解决方案？

任何意见，将不胜感激。

Answer 1

Microservice A only allows linking A to B if it has previously received a "B created" event and no "B deleted" event.

这里有一个潜在的问题；考虑两条消息之间的竞争， link A to B和 B Created .如果 B Created消息恰好首先到达，然后一切都按预期链接。如 B Created碰巧第二次到达，则链接不会发生。简而言之，您的业务行为取决于您的消息管道。
Udi Dahan, 2010

A microsecond difference in timing shouldn’t make a difference to core business behaviors.

A potential disadvantage for solution 2 could maybe be the added complexity of projecting these events in the read model, especially if more microservices and aggregates following the same pattern are added to the system.

我根本不喜欢那种复杂性；这听起来像是很多工作，但没有太大的商业值(value)。
异常报告可能是一个可行的替代方案。 Greg Young talked about this in 2016 .简而言之;拥有一个检测不一致状态的监视器，并修复这些状态，可能就足够了。
稍后会添加自动修复。 Rinat Abdullin described这个进展真的很好。
自动化版本最终看起来类似于解决方案 2；但是随着职责的分离——修复逻辑位于微服务 A 和 B 之外。