我对微服务/CQRS 架构中使用的集成事件有疑问。
事件的有效负载只能有对聚合的引用还是可以有更多的信息？
如果只能发送参考 ID，唯一可行的解决方案是通过某种类型的调用带来其余信息，但源端必须实现一个端点，并且服务最终会更加耦合。
例如。当创建用户并引发事件时。
UserCreated {
userId
name
lastname
document
...
}
这是正确的吗？
【问题讨论】：
标签： domain-driven-design microservices cqrs
如果只能发送参考ID，
为什么只允许这样做？我曾使用过一个使用微服务、CQRS 和 DDD（与您的类似）的系统，我们没有这样的限制。就像在大多数情况下一样：“什么最适合您的应用程序/业务领域”。不要盲目地遵循任何规则。也可以将其他信息放入事件 Payload 中。
唯一可行的解决方案是将其余信息与 某种类型的调用，但源必须实现一个端点 并且服务最终会更加耦合。
这在某些情况下也可以，但这会让您在事件处理后有额外的调用。我不会这样做，除非你有一个非常重的模型/模型，它会影响你的表现。例如，如果您执行了一个基于 userId 的事件，则出于某种原因需要加载相关对象/模型的集合。我有一个类似的情况，我必须根据对用户的某些操作（例如事件 UserCreated）来加载其他对象的集合。当然，在这种情况下，您不想在一个事件有效负载中发送所有数据。相反，您只发送用户的 id，然后从其他服务调用 Get api 以获取该数据并将其保存到您的微服务。
用户创建 {
用户ID
名称
姓氏
文件
... }这是正确的吗？
是的，这很好:)
你可以做什么：
根据您的业务场景，您可以发布具有阶段和不同状态的多个事件的信息。 让我们从 UI 中说，您有一些类似向导的屏幕，其中包含多个创建步骤。你可以发布
这只是某些特定场景的示例，具体取决于您的用例和业务需求。这只是为了给你一个想法，在某些情况下你可以做什么。
总结：
如您所见，您可以通过多种方式使用此类系统。请记住，遵循规则是好的，但在某些情况下，您需要根据您的业务场景做最好的事情，而适用于某些应用程序的方法可能不是您的最佳解决方案。做对您的系统最有效的事情。使用微服务时，无论如何我们都需要处理延迟和异步操作，因此在系统的其他部分节省一些性能总是好的。
【讨论】：