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

Question

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

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

如果只能发送参考ID，则唯一可行的解​​决方案是通过某种类型的呼叫来带走其余信息，但始发者必须实现一个端点，并且服务最终会更加耦合。

恩。 创建用户并引发事件时。

UserCreated {
   userId
   name
   lastname
   document
   ...
}

这个对吗？

Answer 1

如果只能发送参考ID，

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

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

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

用户创建的{
用户身份
名称
姓
文献
...}

这个对吗？

是的，这很好:)

您可以做什么：

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

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

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

摘要：

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