Sacha Barber 在提升自己对 CQRS( Command Query Responsibility Segregation ) 设计所包含的架构和模式的理解过程中，决定构建一个包含事件溯源机制的CQRS 演示程序，并撰写了一篇文章解释内部工作机制。
Barber 是 Microsoft C# MVP ，他将 CQRS 描述为一种分离职责的设计，可以将没有副作用的查询类读操作和更改数据的写操作职责相互分离。他的示例中采用了 Vladimir Khorikov 早先定义的第三种CQRS 实现模式，对于读写职责均使用不同的模型和存储方式。Barber 将事件溯源定义为一种方法，应用将状态的变化存储为一系列事件，并且应用不仅仅只存储当前的状态。为了得到某个对象当前的状态，应用需要取回所有的事件，并在这个对象上顺序回放。这种方法，通过重放某一时点的事件并调整相关状态，来实现追溯应用过去的状态。
使用基于事件的写模型并将读写模型的存储分离，意味着写操作端的变化都需要通过事件机制在读模型中更新。这种更新以异步的方式执行，意味着写模式下的变化可能不会立刻在后续的读操作中反映出来，并且Barber 注意到应用程序当前是处于一种确保最终一致性的状态。基于此，他认为典型的CQRS 实现并不适用于请求返回类型的操作，客户期盼对请求都能有即刻正确的响应。因此，Barber 认为，那些从用户的角度去看，查询和写操作就相互明确区分的业务场景，更加适用于使用CQRS。
为了加深对CQRS 的理解，Barber 基于.Net 平台构建了一个完整的示例程序，包含了CQRS 的所有部分，并使用 RabbitMQ 消息队列实现事件溯源的异步机制，以此作为一种读写模型之间跨进程总线的交互方式。为了简化程序，他尽可能使用内存模型，包括事件的存储实现方式，这意味着程序多次运行之间的数据并不具备持久性。整个应用包含了一个命令总线、一个领域模型、一个写操作端的事件存储、一个事件总线和一个 NoSql 数据库，以及读操作端的事件处理器和一个数据访问层。
人们通常认为现成的 CQRS 框架会对应用实现 CQRS 设计造成障碍，但 Barber 考虑到自身对于 CQRS 经验欠缺，所以还是基于 CQRSlite 构建了示例程序，而 CQRSLite 是对早期 Greg Young 实现的 CQRS 框架的一个扩展。
查看英文原文： Introducing CQRS and Event Sourcing with a Demo Application
感谢丁晓昀对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群
）。
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论