我对如何在基于事件的微服务架构中实现数据验证感到困惑。
让我们总结一些与微服务有关的方面。1.微服务必须是低耦合的。2.微服务更好地面向领域
然后由于互联网上大量的材料和DDD（域驱动设计）中的书籍我创建了下一个基于事件的微服务架构。组件1. API getaway接收来自客户端的REST调用，并将其转换为命令。2 命令处理程序作为服务。从API getaway接收命令进行验证。将事件保存到事件存储，并将事件发布到事件总线。3. 事件存储是系统中所有事件的存储。允许我们重新创建应用程序的状态。真实的主要状态。4. 微服务是负责处理与其域事件相关的小型服务。对本地私有数据库进行一些预测。也进行一些活动。
而且我有一个我自己和互联网都无法回答的问题。1.实际是什么。我认为它们是数据库中的类对象/记录，还是什么？2.谁携带骨料。我发现示例在某些情况下命令处理程序会使用它们。但是这样，如果聚合存储在私有微服务数据库中，那么我们将在命令处理程序和每个微服务之间建立非常高的耦合，并且由于微服务的概念，这是错误的。
总结。我对如何在事件源微服务体系结构中实现聚合感到困惑。例如，让我们关注事件源微服务体系结构中的用户注册实现。
我们拥有用户域，因此架构将是下一个。API逍遥游命令处理程序Auth微服务用户微服务
由于上述示例，请向我解释命令验证的实现。
命令处理程序即服务
我认为这是您困惑的主要根源。
命令处理程序本身通常不是服务。这是一种模式。它通常将与“微服务”本身在同一进程中运行。
IE：命令处理程序从存储中读取一条消息，并且它本身调用微服务逻辑，该逻辑计算如何将该消息中的信息集成到自己的世界视图中。
实际是什么聚合
“聚合”是生命周期管理模式；集合是一个或多个域实体的图，它们将共同建立并保持一些有趣的不变性。这是Eric Evans撰写的《域驱动设计》一书中详细描述的三种模式之一。
命令处理程序加上您的集合是，从某种意义上说，您是微服务。微服务通常将处理单个聚合的多个实例的消息-它将订阅该聚合的所有输入消息。 “处理程序”部分仅读取下一条消息，加载聚合的适当实例，然后执行域逻辑（在聚合实体中定义）并存储结果。