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

Question

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

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

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

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

UserCreated {
   userId
   name
   lastname
   document
   ...
}

这是正确的吗？

Answer 1

If only reference ids can be sent,

为什么只允许这样做？我曾使用过一个使用 micro-services、CQRS 和 DDD（类似于您的系统）的系统，我们没有此类限制。在大多数情况下，它是："What works best for your application/business domain"。不要盲目遵守任何规则。将其他信息也放入事件负载中也完全没问题。

the only viable solution is to bring the rest of the information with some type of call but the origin would have to implement an endpoint and the services would end up more coupled.

这在某些情况下也很好，但这会让您遇到在处理完事件后需要进行额外调用的情况。我不会这样做，除非你有一个非常重的 model/models 并且它会影响你的表现。例如，如果您执行了一个基于 userId 的事件，您将出于某种原因需要加载相关 objects/models 的集合。我有一个类似的情况，我必须根据对用户的某些操作（如事件 UserCreated）加载其他对象的集合。当然，在这种情况下，您不想在一个事件负载中发送所有数据。相反，您只发送用户的 ID，然后从其他服务调用 Get api 以获取该数据并将其保存到您的 micro-service.

UserCreated {
userId
name
lastname
document
... }

Is this correct?

是的，这很好:)

你可以做什么：

根据您的业务场景，您可以发布具有多个阶段和不同状态的事件的信息。假设从 UI 开始，您有一些 Wizard-like 屏幕，其中包含多个创建步骤。你可以发表

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

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

总结：

如您所见，您可以通过多种方式使用此类系统。请记住，遵守规则是好的，但在某些情况下，您需要根据您的业务场景做最好的事情，而适用于某些应用程序的方法可能不是您的最佳解决方案。做对您的系统最有效的事情。使用 micro-services 我们无论如何都需要处理延迟和异步操作，因此在系统的其他部分节省一些性能总是好的。

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

Domain / integration events payload information in DDD CQRS architecture

domain-driven-design

microservices

cqrs