DDD/事件溯源，从另一个微服务获取数据？

Question

不知道你能不能帮忙。我正在编写一个订单系统，目前已经实现了一个负责下订单的订单微服务。我正在使用带有事件溯源和 CQRS 的 DDD。

订单服务本身接受产生事件的命令，实际的订单服务监听自己的事件以创建读取模型（这里的想法是使用CQRS，因此命令用于写入和查询用于读取）

执行上述操作后，我遇到了一个问题，可能只是我没有完全理解这样做的正确方法。

订单实际上有依赖项，这意味着订单需要客户和产品。因此，我将为客户和产品提供 2 个额外的微服务。

为了简单起见，我想专注于客户（虽然我对产品也有完全相同的问题，但我的想法是，如果我解决了客户问题，那么另一个问题也会自动解决）。

回到手头的问题。要创建订单需要客户（和产品），我目前在客户端上有 customerId，因此向订单服务发送命令，我可以传入 customerId。

我想在订单中保存客户的姓名和地址。如何从 Order Service 中的 Customer Service 获取 customerId 的名称和地址？

我想总结一下，当一个服务的数据需要另一个服务的数据时，我如何才能获得这些数据。

订单服务是否会创建一个接收客户记录的事件？这将在系统中引入很多复杂性（更多事件）

微服务不耦合，因此订单服务不能只调用客户的读取模型。

谁能帮我解决这个问题？

Answer 1

我的建议是在前端收集所需的数据并将其传递。您想要非规范化到订单中的相关客户详细信息将是一个值对象。与订单行相关的产品数据（例如 id、描述）也是如此。

让系统交互以检索数据并非不可能，但这确实将它们耦合到似乎必要的较低级别。

Answer 2

当一个服务的数据需要另一个服务的数据时，我如何才能获得这些数据？

你复制它。

因此，在您的设计中的某处需要有一条消息，将数据从它所在的位置传送到它需要的位置。

这可能意味着订单服务订阅客户服务发布的事件，并存储其所需信息的副本。或者可能是订单服务查询了一些 API，这些 API 可以直接访问客户服务存储的数据。

查询您需要的其他数据可以是同步的或异步的 - 也许可以推迟工作，直到您获得所需的所有数据。

另一种可能性是您重新设计您的系统，以便您需要的业务功能与数据有关，或者移动功能或移动数据。为什么订购需要客户数据？客户服务可以代替工作吗？订单是否应该拥有数据？

在您决定跨多个服务分配工作时，存在一定程度的复杂性。分发系统的决定涉及权衡各种权衡。

Answer 3

如果您使用 DDD，首先，请阅读有界上下文。忘记微服务，它们只是实施策略。

现在回到你的问题。从客户聚合中发布这些事件（在您的情况下为客户微服务）：CustomerRegistered、CustomerInfoUpdated、CustomerAccountRemoved、CustomerAddressChanged 等。然后订阅您的订单服务（再次在订单微服务中的应用程序服务中）以收听所有以上事件。好吧，不是全部，只是订单需要。

现在，您可能有一个问题，如果我的大多数或部分客户不下订单怎么办？我的订单服务将充满不必要的数据。这是一个好方法吗？

嗯，答案可能会有所不同。我想说，从性能角度来看，硬盘空间比内存便宜，或者数据库查询比网络调用快。如果您的数据库主机（或您的服务器）受到限制，那么您不应该使用微服务。此外，我会用这些未使用的客户数据提出一些商业想法，例如列出所有从未订购过任何东西的客户，我将向他们发送一些优惠以发展我的业务。开玩笑。不要为微服务中未使用的数据而烦恼。