事件源微服务架构中的命令有效负载验证

Question

我对如何在事件源微服务架构中实现数据验证感到困惑。

让我们总结一下与微服务相关的一些方面。
1. 微服务必须是低耦合的。
2. 微服务最好面向领域

然后由于互联网上的大量材料和 DDD（领域驱动设计）中的书籍 我创建了下一个事件源微服务架构。 组件
1. API getaway 接收来自客户端的 REST 调用并将其转换为命令。
2 命令处理程序作为服务。从 API getaway 接收命令进行验证。将事件保存到事件存储并将事件发布到事件总线。
3. 事件存储是系统中所有事件的存储。允许我们重新创建应用程序的状态。真理的主要状态。
4. 微服务是负责处理与其领域相关的事件的小服务。对本地私有数据库进行一些预测。也做一些活动。

我有一些问题，我自己和互联网都无法回答。
1. 什么是实际聚合。它们是我认为的数据库中的类对象/记录还是什么？
2. 携带聚合体。我发现一些例子是命令处理程序使用它们。但是这样一来，如果聚合存储在私有微服务数据库中，那么命令处理程序和每个微服务之间的耦合度就会很高，这是微服务概念造成的错误。

总结一下。
我对如何在事件源微服务架构中实现聚合感到困惑。
比如让我们关注事件源微服务架构中的用户注册实现。

我们有用户域，因此架构将是下一个。
API getaway
命令处理程序
身份验证微服务
用户微服务

请根据上面的例子解释一下命令验证的实现。

Answer 1

作为服务的命令处理程序

我认为这是你困惑的主要原因。

命令处理程序本身通常不是服务。它是一种模式。它通常与“微服务”本身在同一进程中运行。

IE：命令处理程序从 so storage 中读取消息，并自己调用微服务逻辑，该逻辑计算如何将消息中的信息集成到自己的世界视图中。

什么是真正的聚合

“聚合”是一种生命周期管理模式；聚合是一个或多个域实体的图，它们将共同建立和维护一些有趣的不变量。它是 Eric Evans 撰写的《领域驱动设计》一书中详细描述的三种模式之一。

命令处理程序加上你的聚合是，在某种意义上，你的微服务。微服务通常会处理单个聚合的多个实例的消息——它将订阅该聚合的所有输入消息。 “处理程序”部分只是读取下一条消息，加载适当的聚合实例，然后执行域逻辑（在聚合实体中定义）并存储结果。