Question

我对微服务/ CQRS架构中使用的集成事件有疑问。

事件的有效负载只能引用聚合，还是可以有更多信息？

如果仅可以发送参考ID，则唯一可行的解决方案是通过某种类型的调用带来其余信息，但是源必须实现端点，并且服务最终会更加耦合。

例如创建用户并引发事件时。

UserCreated {
   userId
   name
   lastname
   document
   ...
}

这正确吗？

Answer 1

如果只能发送参考ID，

为什么只允许这样做？我使用的系统使用微服务，CQRS和DDD（与您的类似），但我们没有此类限制。在大多数情况下，它是：“最适合您的应用程序/业务领域的内容”。不要盲目遵循任何规则。将其他信息也放入事件有效负载中也很好。

唯一可行的解决方案是将其余信息与某种类型的呼叫，但始发者必须实现一个端点服务最终会更加耦合。

在某些情况下也可以，但是这会导致您在处理事件后遇到其他呼叫。除非您的模型非常笨重，否则我不会这样做，否则会影响您的性能。例如，如果您执行了一个事件并基于userId，则出于某种原因您将需要加载相关对象/模型的集合。我有一种类似的情况，我必须基于对用户的某些操作（例如事件UserCreated）加载其他对象的集合。当然，在这种情况下，您不想在一个事件有效负载中发送所有数据。取而代之的是，您仅发送用户的ID，然后从其他服务调用Get api，以获取该数据并将其保存到您的微服务中。

UserCreated   {
      userId
      名称
      姓氏
      文件
  ...}

这正确吗？

是的，这很好：）

您可以做什么：

根据您的业务场景，您可以在阶段和不同州发布具有多个事件的信息。可以说，从用户界面中可以看到类似向导的屏幕，其中包含多个创建步骤。您可以发布

1. 事件：UserCreatedDraft，其中包含来自第一个向导页面的一些初始数据
1. 事件：UserPersonalDataCreated仅与私有数据相关的对象的一部分
1. 事件：UserPaymentDataCreated仅创建了付款数据
1. 最后一步的UserCreatedFinal

这只是某些特定情况的示例，具体情况取决于您的用例和业务需求。这只是为了让您了解在某些情况下可以做什么。

摘要：

如您所见，使用这种系统有多种方法。请记住，遵循规则是好的，但是在某些情况下，您需要根据业务场景执行最佳方法，并且对某些应用程序有效的方法可能不是最佳的解决方案。做对您的系统最有效的事情。使用微服务，无论如何我们都需要处理延迟和异步操作，因此在系统的其他部分保存一些性能始终是很好的。

DDD CQRS架构中的域/集成事件有效负载信息

1 个答案: