命令触发操作，操作触发领域事件。领域事件保存在事件存储中，也就是“一个将数据库与消息代理相结合的系统。”最合适入门使用的事件存储是Eventuate，是由Chris Richardson创建的项目，旨在帮助将CQRS和Event Sourcing应用到微服务。
领域事件存储为按时间顺序排列的一系列事件，附加在日志上。由于每个命令都生成一个事件，我们能够根据收集的事件历史记录重新构建当前系统的总体状态。
事件处理器
我们要探讨的下一个组件是事件处理器。这个CQRS组件采用Worker应用的形式，负责摄取领域事件。事件处理器是无状态的，并侦听来自事件存储的消息，对传入的事件消息采取操作。
事件处理器可通过很多有用的方式对新的领域事件作出响应。一个领域事件可以生成多个事件，这些事件可以发送到其他微服务。这就是为什么大多数微服务开发人员都被CQRS吸引，因为通过这种方法可以发布和订阅来自限界环境之外的应用的领域事件。
这种方法为我们提供了一种机制，可确保领域数据的引用完整性。来自其他微服务的消息可用来处理领域事件，从而让我们能够维护分布式系统中与其他记录的领域数据相关的恼人的外键关系。
查询端
事件处理器首要负责应用可改变领域整合状态的领域事件。每个领域事件都可用来更新数据库记录，形成描述整合的增量实体化视图。反过来，查询端将提供一个REST API，允许HTTP客户端读取从已处理事件生成的实体化视图。
查询端组件中的限制是领域数据是只读的。此系统中的所有状态更改都会从命令端流入，然后形成可在查询端读取的实体化视图。
是分布式一体化还是微服务？
如今，大多数人想到单个微服务时，他们想到的是一个独立的服务组件。在大多数情况下，微服务被构建为应用，专注于处理好一件事情。最重要的是，这种服务可以独立于其他服务进行升级和部署。
现在，如果说到传统的CQRS实施，如果由于组件相互分离就称之为微服务，似乎有些不妥。因此我们得问一句：可以将CQRS应用视为微服务吗？或者换种说法，可以像某些开发人员那样，开始称之为分布式一体化吗？对于这个问题，不同的人会有不同的答案。微服务主要是让小型独立团队有能力持续交付功能，作为其他微服务组成的更大生态系统的一部分。
如果与大多数微服务部署相比，CQRS部署是十分复杂的。对于微服务团队来说，能够持续将功能交付至生产是目标。由于CQRS中分离的组件仍可以独立部署，我们可以说每个部署单元仍可满足独立将功能交付至生产的最低要求。微服务的一个功能应该始终需要且最多一个可部署单元。当交付一项功能时需要同时协调部署多个单独组件，就会产生所谓的分布式一体化。
微服务和无服务器
无服务器也称为FaaS（功能即服务），可让您在不需要设置或管理应用服务器或容器的情况下，将代码部署为功能。无服务器是一种新型架构风格，在构建和运行云原生应用方面越来越受到关注。使用无服务器功能的一个显著优势是，事件概念被优先处理。
有很多人以为，微服务和无服务器不兼容，彼此的架构风格完全不同。但是回想一下前面提到的CQRS你就会明白，这种想法是错误的。让我们来看一个场景，你认为在此场景中微服务的边界在哪里？
一种方法是认为微服务的边界就是团队的边界。只要一个团队可以独立、连续地将特性部署为功能，那么微服务的边界就只是负责为团队拥有的特性提供支持的功能子集。
权衡
要采用微服务和无服务器相结合的方法，需要您仔细权衡多项内容，让我们来看看需要注意的事项。
速度
对于微服务来说，速度就是目标。我们可以通过关注以下两个问题来衡量速度，平均时间越低，团队交付功能的速度就越快。：