在日常工作中，我们经常会遇到代码组织不合理的现象，导致系统复杂性不断叠加，陷入难以自拔的困境。

一、什么是CQRS？

CQRS（Command Query Responsibility Segregation，命令查询职责分离）是一种流行的业务架构和设计思维，其核心思想是将系统的写操作（命令）和读操作（查询）分离。

CRQS的目的在于降低系统复杂性，背后的逻辑是：

如果使用相同的模型处理命令和查询，在极端情况下，系统复杂度为 MN，因为两者相互影响。 如果将命令和查询彻底分离，系统的复杂度变为 M+N，因为命令的变更不会影响查询，反之亦然。

在实际工作中，系统的复杂度通常介于这两个极端之间。但拆分的思想无处不在，冲突的存在正是拆分的暗示。

二、分层架构中的冲突

以常见的五层分层架构为例：

• 接入层： HTTP/RPC 接入接口
• 应用服务层： 业务逻辑和领域操作
• 模型层： 业务领域实体和领域逻辑
• 仓库层： 提供对持久化数据的访问
• 数据层： 数据持久化和底层数据库交互

除了横向分层，还可以基于 CQRS 对每个层纵向拆分，将组件拆分为命令和查询两部分。

三、应用服务层冲突与拆分

应用服务层拆分就是将一个应用服务拆分为 CommandService 和 QueryService 两组。这可以避免许多不必要的麻烦，因为命令和查询存在很大差异：

| 特征 |命令 | 查询 | |---|---|---| | 目的 | 改变系统状态 | 检索系统状态 | | 响应时间 | 慢，因为涉及数据库更新 | 快，因为通常使用缓存 | | 事务 | 通常需要事务处理 | 通常不需要事务处理 | | 并发 | 敏感，避免并发更新 | 不敏感 |

应用层拆分可以解决以下冲突：

使用错误的组件执行命令或查询 为命令设计一个查询 API，反之亦然 统一的操作流程重复的模板代码

四、模型层冲突与拆分

模型层是系统的核心，其设计直接影响整个系统的质量。模型可以采用多种比较流程实现策略：

贫血模型： 只包含数据字段，不包含任何业务逻辑 充血模型： 包含数据字段和业务逻辑 领域驱动模型： 基于充血模型，进一步强调领域概念和领域规则

没有哪种方案是最佳的，不同的应用场景需要不同的选择。基于 CQRS，可以将模型拆分为 Command Model 和 Query Model：

Command Model：

专注于变更系统状态 通常包括实体的当前状态和历史状态 采用充血模型或领域驱动模型

Query Model：

专门用于检索系统状态 通常采用贫血模型或充血模型 优化查询性能和减少加载数据

模型拆分后，新模型具有以下特征：

解耦命令和查询 提高模型的可维护性 优化查询性能

五、仓库层冲突与拆分

仓库层拆分也是非常必要的，这一层的主要冲突包括：

同时处理命令和查询 脏读和竞争更新

仓库拆分后，整体架构如下：

• Command 仓库： 专注于处理命令，更新数据库
• Query 仓库： 专注于处理查询，读取数据库

仓库拆分具有以下特点：

解耦命令和查询 避免脏读和竞争更新 提高并发性和吞吐量

六、数据层冲突与拆分

数据层拆分是最重要的拆分，提到分离第一反应也是数据库主从分离。但 CQRS 数据层拆分不仅仅是主从分离，它还包括：

Event Sourcing： 将系统状态变化记录为一个事件流，而不是直接更新数据库 Command Query Optimization： 根据命令和查询的不同特点优化数据库架构和索引

数据层拆分可以带来以下好处：

增强系统弹性 提高查询性能 支持更多复杂的数据操作

结论

CQRS 是一种强大的设计思维，通过拆分命令和查询来降低系统复杂性。这种拆分可以应用于分层架构的各个层级，包括应用服务层、模型层、仓库层和数据层。通过采用 CQRS，我们可以创建更灵活、可维护和可扩展的系统。

---

什么是DDD（领域驱动设计）？ 这是我见过最容易理解的一篇关于DDD 的文章了

领域驱动设计之领域模型

加一个导航，关于如何设计聚合的详细思考，见这篇文章。

2004年Eric Evans 发表Domain-Driven Design –Tackling Complexity in the Heart of Software （领域驱动设计），简称Evans DDD。领域驱动设计分为两个阶段：

以一种领域专家、设计人员、开发人员都能理解的通用语言作为相互交流的工具，在交流的过程中发现领域概念，然后将这些概念设计成一个领域模型；由领域模型驱动软件设计，用代码来实现该领域模型；

由此可见，领域驱动设计的核心是建立正确的领域模型。

为什么建立一个领域模型是重要的

领域驱动设计告诉我们，在通过软件实现一个业务系统时，建立一个领域模型是非常重要和必要的，因为领域模型具有以下特点：

.领域模型是对具有某个边界的领域的一个抽象，反映了领域内用户业务需求的本质；领域模型是有边界的，只反应了我们在领域内所关注的部分；

.领域模型只反映业务，和任何技术实现无关；领域模型不仅能反映领域中的一些实体概念，如货物，书本，应聘记录，地址，等；还能反映领域中的一些过程概念，如资金转账，等；

.领域模型确保了我们的软件的业务逻辑都在一个模型中，都在一个地方；这样对提高软件的可维护性，业务可理解性以及可重用性方面都有很好的帮助；

.领域模型能够帮助开发人员相对平滑地将领域知识转化为软件构造；

.领域模型贯穿软件分析、设计，以及开发的整个过程；领域专家、设计人员、开发人员通过领域模型进行交流，彼此共享知识与信息；因为大家面向的都是同一个模型，所以可以防止需求走样，可以让软件设计开发人员做出来的软件真正满足需求；

.要建立正确的领域模型并不简单，需要领域专家、设计、开发人员积极沟通共同努力，然后才能使大家对领域的认识不断深入，从而不断细化和完善领域模型；

.为了让领域模型看的见，我们需要用一些方法来表示它；图是表达领域模型最常用的方式，但不是唯一的表达方式，代码或文字描述也能表达领域模型；

.领域模型是整个软件的核心，是软件中最有价值和最具竞争力的部分；设计足够精良且符合业务需求的领域模型能够更快速的响应需求变化；

领域通用语言（UBIQUITOUS LANGUAGE）

我们认识到由软件专家和领域专家通力合作开发出一个领域的模型是绝对需要的，但是，那种方法通常会由于一些基础交流的障碍而存在难点。开发人员满脑子都是类、方法、算法、模式、架构，等等，总是想将实际生活中的概念和程序工件进行对应。他们希望看到要建立哪些对象类，要如何对对象类之间的关系建模。他们会习惯按照封装、继承、多态等面向对象编程中的概念去思考，会随时随地这样交谈，这对他们来说这太正常不过了，开发人员就是开发人员。但是领域专家通常对这一无所知，他们对软件类库、框架、持久化甚至数据库没有什么概念。他们只了解他们特有的领域专业技能。比如，在空中交通监控样例中，领域专家知道飞机、路线、海拔、经度、纬度，知道飞机偏离了正常路线，知道飞机的发射。他们用他们自己的术语讨论这些事情，有时这对于外行来说很难直接理解。如果一个人说了什么事情，其他的人不能理解，或者更糟的是错误理解成其他事情，又有什么机会来保证项目成功呢？

在交流的过程中，需要做翻译才能让其他的人理解这些概念。开发人员可能会努力使用外行人的语言来解析一些设计模式，但这并一定都能成功奏效。领域专家也可能会创建一种新的行话以努力表达他们的这些想法。在这个痛苦的交流过程中，这种类型的翻译并不能对知识的构建过程产生帮助。

领域建模时思考问题的角度

“用户需求”不能等同于“用户”，捕捉“用户心中的模型”也不能等同于“以用户为核心设计领域模型”。 《老子》书中有个观点：有之以为利，无之以为用。在这里，有之利，即建立领域模型；无之用，即包容用户需求。举些例子，一个杯子要装满一杯水，我们在制作杯子时，制作的是空杯子，即要把水倒出来，之后才能装下水；再比如，一座房子要住人，我们在建造房子时，建造的房子是空的，唯有空的才能容纳人的居住。因此，建立领域模型时也要将用户置于模型之外，这样才能包容用户的需求。

所以，我的理解是：

.我们设计领域模型时不能以用户为中心作为出发点去思考问题，不能老是想着用户会对系统做什么；而应该从一个客观的角度，根据用户需求挖掘出领域内的相关事物，思考这些事物的本质关联及其变化规律作为出发点去思考问题。

.领域模型是排除了人之外的客观世界模型，但是领域模型包含人所扮演的参与者角色，但是一般情况下不要让参与者角色在领域模型中占据主要位置，如果以人所扮演的参与者角色在领域模型中占据主要位置，那么各个系统的领域模型将变得没有差别，因为软件系统就是一个人机交互的系统，都是以人为主的活动记录或跟踪；比如：论坛中如果以人为主导，那么领域模型就是：人发帖，人回帖，人结贴，等等；DDD的例子中，如果是以人为中心的话，就变成了：托运人托运货物，收货人收货物，付款人付款，等等；因此，当我们谈及领域模型时，已经默认把人的因素排除开了，因为领域只有对人来说才有意义，人是在领域范围之外的，如果人也划入领域，领域模型将很难保持客观性。领域模型是与谁用和怎样用是无关的客观模型。归纳起来说就是，领域建模是建立虚拟模型让我们现实的人使用，而不是建立虚拟空间，去模仿现实。

领域驱动设计的经典分层架构

用户界面/展现层

负责向用户展现信息以及解释用户命令。更细的方面来讲就是：

.请求应用层以获取用户所需要展现的数据；

.发送命令给应用层要求其执行某个用户命令；

应用层

很薄的一层，定义软件要完成的所有任务。对外为展现层提供各种应用功能（包括查询或命令），对内调用领域层（领域对象或领域服务）完成各种业务逻辑，应用层不包含业务逻辑。

领域层

负责表达业务概念，业务状态信息以及业务规则，领域模型处于这一层，是业务软件的核心。

基础设施层

本层为其他层提供通用的技术能力；提供了层间的通信；为领域层实现持久化机制；总之，基础设施层可以通过架构和框架来支持其他层的技术需求；

领域驱动设计过程中使用的模式

所有模式的总揽图

关联的设计

关联本身不是一个模式，但它在领域建模的过程中非常重要，所以需要在探讨各种模式之前，先讨论一下对象之间的关联该如何设计。我觉得对象的关联的设计可以遵循如下的一些原则：

.关联尽量少，对象之间的复杂的关联容易形成对象的关系网，这样对于我们理解和维护单个对象很不利，同时也很难划分对象与对象之间的边界；另外，同时减少关联有助于简化对象之间的遍历；

.对多的关联也许在业务上是很自然的，通常我们会用一个集合来表示1对多的关系。但我们往往也需要考虑到性能问题，尤其是当集合内元素非常多的时候，此时往往需要通过单独查询来获取关联的集合信息；

.关联尽量保持单向的关联；

.在建立关联时，我们需要深入去挖掘是否存在关联的限制条件，如果存在，那么最好把这个限制条件加到这个关联上；往往这样的限制条件能将关联化繁为简，即可以将多对多简化为1对多，或将1对多简化为1对1；

实体（Entity）

实体就是领域中需要唯一标识的领域概念。因为我们有时需要区分是哪个实体。有两个实体，如果唯一标识不一样，那么即便实体的其他所有属性都一样，我们也认为他们两个不同的实体；因为实体有生命周期，实体从被创建后可能会被持久化到数据库，然后某个时候又会被取出来。所以，如果我们不为实体定义一种可以唯一区分的标识，那我们就无法区分到底是这个实体还是哪个实体。

另外，不应该给实体定义太多的属性或行为，而应该寻找关联，发现其他一些实体或值对象，将属性或行为转移到其他关联的实体或值对象上。比如Customer实体，他有一些地址信息，由于地址信息是一个完整的有业务含义的概念，所以，我们可以定义一个Address对象，然后把Customer的地址相关的信息转移到Address对象上。如果没有Address对象，而把这些地址信息直接放在Customer对象上，并且如果对于一些其他的类似Address的信息也都直接放在Customer上，会导致Customer对象很混乱，结构不清晰，最终导致它难以维护和理解；

值对象（Value Object）

在领域中，并不是没一个事物都必须有一个唯一标识，也就是说我们不关心对象是哪个，而只关心对象是什么。就以上面的地址对象Address为例，如果有两个Customer的地址信息是一样的，我们就会认为这两个Customer的地址是同一个。也就是说只要地址信息一样，我们就认为是同一个地址。用程序的方式来表达就是，如果两个对象的所有的属性的值都相同我们会认为它们是同一个对象的话，那么我们就可以把这种对象设计为值对象。因此，值对象没有唯一标识，这是它和实体的最大不同。

另外值对象在判断是否是同一个对象时是通过它们的所有属性是否相同，如果相同则认为是同一个值对象；而我们在区分是否是同一个实体时，只看实体的唯一标识是否相同，而不管实体的属性是否相同；值对象另外一个明显的特征是不可变，即所有属性都是只读的。因为属性是只读的，所以可以被安全的共享；当共享值对象时，一般有复制和共享两种做法，具体采用哪种做法还要根据实际情况而定；另外，我们应该给值对象设计的尽量简单，不要让它引用很多其他的对象，因为他只是一个值，就像int a = 3;那么”3”就是一个我们传统意义上所说的值，而值对象其实也可以和这里的”3”一样理解，也是一个值，只不过是用对象来表示。所以，当我们在C#语言中比较两个值对象是否相等时，会重写GetHashCode和Equals这两个方法，目的就是为了比较对象的值；值对象虽然是只读的，但是可以被整个替换掉。就像你把a的值修改为”4”(a = 4;)一样，直接把”3”这个值替换为”4”了。值对象也是一样，当你要修改Customer的Address对象引用时，不是通过这样的方式来实现，因为值对象是只读的，它是一个完整的不可分割的整体。我们可以这样做 = new Address(…);

应用层服务

.获取输入（如一个XML请求）；

.发送消息给领域层服务，要求其实现转帐的业务逻辑；

.领域层服务处理成功，则调用基础层服务发送Email通知；

领域层服务

.获取源帐号和目标帐号，分别通知源帐号和目标帐号进行扣除金额和增加金额的操作；

.提供返回结果给应用层；

基础层服务

按照应用层的请求，发送Email通知；

所以，从上面的例子中可以清晰的看出，每种服务的职责；

聚合及聚合根（Aggregate，Aggregate Root）

聚合，它通过定义对象之间清晰的所属关系和边界来实现领域模型的内聚，并避免了错综复杂的难以维护的对象关系网的形成。聚合定义了一组具有内聚关系的相关对象的集合，我们把聚合看作是一个修改数据的单元。

聚合有以下一些特点：

.每个聚合有一个根和一个边界，边界定义了一个聚合内部有哪些实体或值对象，根是聚合内的某个实体；

.聚合内部的对象之间可以相互引用，但是聚合外部如果要访问聚合内部的对象时，必须通过聚合根开始导航，绝对不能绕过聚合根直接访问聚合内的对象，也就是说聚合根是外部可以保持 对它的引用的唯一元素；

.聚合内除根以外的其他实体的唯一标识都是本地标识，也就是只要在聚合内部保持唯一即可，因为它们总是从属于这个聚合的；

.聚合根负责与外部其他对象打交道并维护自己内部的业务规则；

.基于聚合的以上概念，我们可以推论出从数据库查询时的单元也是以聚合为一个单元，也就是说我们不能直接查询聚合内部的某个非根的对象；

.聚合内部的对象可以保持对其他聚合根的引用；

.删除一个聚合根时必须同时删除该聚合内的所有相关对象，因为他们都同属于一个聚合，是一个完整的概念；

如何识别聚合根？

如果一个聚合只有一个实体，那么这个实体就是聚合根；如果有多个实体，那么我们可以思考聚合内哪个对象有独立存在的意义并且可以和外部直接进行交互。

工厂（Factory）

DDD中的工厂也是一种体现封装思想的模式。DDD中引入工厂模式的原因是：有时创建一个领域对象是一件比较复杂的事情，不仅仅是简单的new操作。正如对象封装了内部实现一样（我们无需知道对象的内部实现就可以使用对象的行为），工厂则是用来封装创建一个复杂对象尤其是聚合时所需的知识，工厂的作用是将创建对象的细节隐藏起来。客户传递给工厂一些简单的参数，然后工厂可以在内部创建出一个复杂的领域对象然后返回给客户。

领域模型中其他元素都不适合做这个事情，所以需要引入这个新的模式，工厂。工厂在创建一个复杂的领域对象时，通常会知道该满足什么业务规则（它知道先怎样实例化一个对象，然后在对这个对象做哪些初始化操作，这些知识就是创建对象的细节），如果传递进来的参数符合创建对象的业务规则，则可以顺利创建相应的对象；但是如果由于参数无效等原因不能创建出期望的对象时，应该抛出一个异常，以确保不会创建出一个错误的对象。当然我们也并不总是需要通过工厂来创建对象，事实上大部分情况下领域对象的创建都不会太复杂，所以我们只需要简单的使用构造函数创建对象就可以了。隐藏创建对象的好处是显而易见的，这样可以不会让领域层的业务逻辑泄露到应用层，同时也减轻了应用层的负担，它只需要简单的调用领域工厂创建出期望的对象即可。

仓储（Repository）

.仓储被设计出来的目的是基于这个原因：领域模型中的对象自从被创建出来后不会一直留在内存中活动的，当它不活动时会被持久化到数据库中，然后当需要的时候我们会重建该对象；重建对象就是根据数据库中已存储的对象的状态重新创建对象的过程；所以，可见重建对象是一个和数据库打交道的过程。从更广义的角度来理解，我们经常会像集合一样从某个类似集合的地方根据某个条件获取一个或一些对象，往集合中添加对象或移除对象。也就是说，我们需要提供一种机制，可以提供类似集合的接口来帮助我们管理对象。仓储就是基于这样的思想被设计出来的；

设计领域模型的一般步骤

.根据需求建立一个初步的领域模型，识别出一些明显的领域概念以及它们的关联，关联可以暂时没有方向但需要有（1：1，1：N，M：N）这些关系；可以用文字精确的没有歧义的描述出每个领域概念的涵义以及包含的主要信息；

.分析主要的软件应用程序功能，识别出主要的应用层的类；这样有助于及早发现哪些是应用层的职责，哪些是领域层的职责；

.进一步分析领域模型，识别出哪些是实体，哪些是值对象，哪些是领域服务；

.分析关联，通过对业务的更深入分析以及各种软件设计原则及性能方面的权衡，明确关联的方向或者去掉一些不需要的关联；

.找出聚合边界及聚合根，这是一件很有难度的事情；因为你在分析的过程中往往会碰到很多模棱两可的难以清晰判断的选择问题，所以，需要我们平时一些分析经验的积累才能找出正确的聚合根；

.为聚合根配备仓储，一般情况下是为一个聚合分配一个仓储，此时只要设计好仓储的接口即可；

.走查场景，确定我们设计的领域模型能够有效地解决业务需求；

.考虑如何创建领域实体或值对象，是通过工厂还是直接通过构造函数；

.停下来重构模型。寻找模型中觉得有些疑问或者是蹩脚的地方，比如思考一些对象应该通过关联导航得到还是应该从仓储获取？聚合设计的是否正确？考虑模型的性能怎样，等等；

关于Unit of Work（工作单元）的几种实现方法

.基于快照的实现，即领域对象被取出来后，会先保存一个备份的对象，然后当在做持久化操作时，将最新的对象的状态和备份的对象的状态进行比较，如果不相同，则认为有做过修改，然后进行持久化；这种设计的好处是对象不用告诉工作单元自己的状态修改了，而缺点也是显而易见的，那就是性能可能会低，备份对象以及比较对象的状态是否有修改的过程在当对象本身很复杂的时候，往往是一个比较耗时的步骤，而且要真正实现对象的深拷贝以及判断属性是否修改还是比较困难的；

.不基于快照，而是仓储的相关更新或新增或删除接口被调用时，仓储通知工作单元某个对象被新增了或更新了或删除了。这样工作单元在做数据持久化时也同样可以知道需要持久化哪些对象了；这种方法理论上不需要ORM框架的支持，对领域模型也没有任何倾入性，同时也很好的支持了工作单元的模式。对于不想用高级ORM框架的朋友来说，这种方法挺好；

对于不会影响领域层中领域对象状态的查询功能

可以直接通过仓储查询出所需要的数据。但一般领域层中的仓储提供的查询功能也许不能满足界面显示的需要，则可能需要多次调用不同的仓储才能获取所需要显示的数据；其实针对这种查询的情况，我在后面会讲到可以直接通过CQRS的架构来实现。

即对于查询，我们可以在应用层不调用领域层的任何东西，而是直接通过某个其他的用另外的技术架构实现的查询引擎来完成查询，比如直接通过构造参数化SQL的方式从数据库一个表或多个表中查询出任何想要显示的数据。这样不仅性能高，也可以减轻领域层的负担。领域模型不太适合为应用层提供各种查询服务，因为往往界面上要显示的数据是很多对象的组合信息，是一种非对象概念的信息，就像报表；

面向对象的实质就是边界划分，封装，不但对需求变化能够量化，缩小影响面；因为边界划分也会限制出错的影响范围，所以OO对软件后期BUG等出错也有好处。

软件世界永远都有BUG,BUG是清除不干净的，就像人类世界永远都存在不完美和阴暗面，问题关键是：上帝用空间和时间的边界把人类世界痛苦灾难等不完美局限在一个范围内；而软件世界如果你不采取OO等方法进行边界划分的话，一旦出错，追查起来情况会有多糟呢？

软件世界其实类似人类现实世界，有时出问题了，探究原因一看，原来是两个看上去毫无联系的因素导致的，古人只好经常求神拜佛，我们程序员在自己的软件上线运行时，大概心里也在求神拜佛别出大纰漏，如果我们的软件采取OO封装，我们就会坦然些，肯定会出错，但是我们已经预先划定好边界，所以，不会产生严重后果，甚至也不会出现难以追查的魔鬼BUG。

四色原型分析模式

时刻-时间段原型（Moment-Interval Archetype）

表示在某个时刻或某一段时间内发生的某个活动。使用粉红色表示，简写为MI。

参与方-地点-物品原型（Part-Place-Thing Archetype）

表示参与某个活动的人或物，地点则是活动的发生地。使用绿色表示。简写为PPT。

描述原型（Description Archetype）

表示对PPT的本质描述。它不是PPT的分类！Description是从PPT抽象出来的不变的共性的属性的集合。使用蓝色表示，简写为DESC。

举个例子，有一个人叫张三，如果某个外星人问你张三是什么？你会怎么说？可能会说，张三是个人，但是外星人不知道“人”是什么。然后你会怎么办？你就会说：张三是个由一个头、两只手、两只脚，以及一个身体组成的客观存在。虽然这时外星人仍然不知道人是什么，但我已经可以借用这个例子向大家说明什么是“Description”了。在这个例子中，张三就是一个PPT，而“由一个头、两只手、两只脚，以及一个身体组成的客观存在”就是对张三的Description，头、手、脚、身体则是人的本质的不变的共性的属性的集合。但我们人类比较聪明，很会抽象总结和命名，已经把这个Description用一个字来代替了，那就是“人”。所以就有所谓的张三是人的说法。

角色原型（Role Archetype）

角色就是我们平时所理解的“身份”。使用黄色表示，简写为Role。为什么会有角色这个概念？因为有些活动，只允许具有特定角色（身份）的PPT（参与者）才能参与该活动。比如一个人只有具有教师的角色才能上课（一种活动）；一个人只有是一个合法公民才能参与选举和被选举；但是有些活动也是不需要角色的，比如一个人不需要具备任何角色就可以睡觉（一种活动）。当然，其实说人不需要角色就能睡觉也是错误的，错在哪里？因为我们可以这样理解：一个客观存在只要具有“人”的角色就能睡觉，其实这时候，我们已经把DESC当作角色来看待了。所以，其实角色这个概念是非常广的，不能用我们平时所理解的狭义的“身份”来理解，因为“教师”、“合法公民”、“人”都可以被作为角色来看待。因此，应该这样说：任何一个活动，都需要具有一定角色的参与者才能参与。

用一句话来概括四色原型就是：一个什么什么样的人或组织或物品以某种角色在某个时刻或某段时间内参与某个活动。 其中“什么什么样的”就是DESC，“人或组织或物品”就是PPT，“角色”就是Role，而”某个时刻或某段时间内的某个活动就是MI。

以上这些东西如果在学习了DDD之后再去学习会对DDD有更深入的了解，但我觉得DDD相对比较基础，如果我们在已经了解了DDD的基础之上再去学习这些东西会更加有效和容易掌握。

如何基于一个现有的系统进行cqrs改造

IDDD 实现领域驱动设计－一个简单的 CQRS 示例

学习架构知识，需要有一些功底和经验，要不然你会和我一样吃力，CQRS、EDA、ES、Saga 等等，这些是实践 DDD 所必不可少的架构，所以，如果你不懂这些，是很难看懂上篇所提到的 CQRS Journey 和 ENode 项目，那怎么办呢？我们可以从简单的 Demo 一点一滴开始。

说明：一张很丑陋的图

所描述的一个流程是 SendMessage（发消息），也就是之前 MessageManager 中的一个业务示例，这个业务流程用到 CQRS 示例中，可能会有些不太准确，或者是有些牵强，但我主要的目的是想做一次 Commond->Event 的过程，熟悉它们到底是怎么交互的？所以，你查看代码的时候，尽量忽略这个业务流程，当然，如果你有针对这个业务流程更好的具体应用，我是非常欢迎交流。

首先，我们根据上面的流程图一步一步进行，UI 创建一个 Commond，然后交给 CommandBus 进行 Send（发送），也就是下面这段代码：

var commond = new SendMessageCommond(){Title = this is title,Content = this is content,SenderLoginName = this is senderLoginName,RecipientDisplayName = this is recipientDisplayName};var commandBus = <CommandBus>();(commond);

项目中所有的类型映射都是通过 IoC 进行注入，ICommandBus 接口定义为：void Send<TCommand>(TCommand cmd) where TCommand : ICommand;，CommandBus 的实现主要是在 Send 方法中，解析 ICommandHandler<TCommand> 注入的类型对象，然后调用 ICommandHandler 接口定义的 Handle 方法，传入 TCommand 参数对象。

SendMessageCommond 的定义很简单，主要是一些来自 UI 的参数，所以，我们一般会定义一些属性字段，有时候我们会进行数据验证，可以使用 Validate，方法签名是： IEnumerable<ValidationResult> Validate(ValidationContext validationContext)，不过需要继承 IValidatableObject 接口，这样我们就可以在 MVC View 前端进行输出验证结果，使用起来非常方便，SendMessageCommond 继承一个无实现的 ICommand 接口，主要用来约束类型，SendMessageCommond 对应 SendMessageCommondHandler，实现代码：

public class SendMessageCommondHandler : ICommandHandler<SendMessageCommond>{public void Handle(SendMessageCommond command){var sender = ();var receiver = ();var message = new Message(, , sender, receiver);();}}

CommondHandler 的功能有点类似于经典分层架构中的 Application（应用层），从它的具体实现中，我们就可以看出领域到底在做哪些工作，它的主要工作就是协调这些工作的流程，领域中的代码我就不贴了，这里我简单说明一下，在之前的 SendMessage 实现中，设计了一个 SendMessageService 领域服务，里面主要进行的工作是验证收发件人，以及消息是否符合规则，后来我就想，SendMessageService 和它实际进行的工作不相符，发消息所蕴含的实际业务意义，我也一直没有想明白，但是在具体实现中，发消息所做的工作是验证，那验证是不是发消息真正的业务含义呢？所以，稀里糊涂就有了上面的代码，VerifySenderService 和 VerifyReceiverService 是用来验证收发件人信息的，成功的话就返回一个 Contact 对象，具体的验证逻辑可以查看下实现代码。

下面说一下 ();，这个可能有很大的问题，在 CQRS Journey 项目中，有很多类似于这样的操作，就是在 CommondHandler 中，创建一个聚合根对象，然后执行聚合根中的一个行为，比如我搜刮的 ()，订单可以提交自己吗？消息可以发送自己吗？这样做的含义是什么？其实我也搞不太清楚，在 Message 聚合根中的 Send 方法中，主要是事件的发布，

public void Send(){(new MessageSentEvent(this));}

先抛开 Send 的合理性，看下 EventBus 是如何 Publish 的？我的实现中和 CommondBus 很相似，但我觉得可能有些问题，Commond 和 CommondHandler 是一一对应关系，我们知道事件发布和事件订阅是一对多关系，也就是说一个事件可能有很对的订阅者，这些订阅者所处理的过程可能会有些不同，比如用户注册的一个事件，可能会有邮件通知订阅者，也可能会有统计数据更新订阅者，在 CQRS Journey 项目中，EventBus 的 Publish 大概是这样实现的：

public void Publish(Envelope<IEvent> @event){var message = (@event);(message);}private Message BuildMessage(Envelope<IEvent> @event){using (var payloadWriter = new StringWriter()){(payloadWriter, );return new Message((), correlationId: );}}

而我的实现则是和 CommondBus 一样，都是用 IoC 注入的，所以肯定有问题，我们来看下 MessageSentEventHandler 中的代码：

public class MessageSentEventHandler : IEventHandler<MessageSentEvent>,IEventHandler<MailSentEvent>{private IEventBus eventBus;public void Handle(MessageSentEvent @event){eventBus = <IEventBus>();new MessageRepository()<Message>();(new MailSentEvent{Title = ,Content = ,});}public void Handle(MailSentEvent @event){var mailMessage = new (); = ; = ; = true; = 8; = ; smtpClient = new ();(() => { (mailMessage, ); });}}

消息发送之后，进行持久化操作，然后再进行邮件通知，这样一整个 SendMessage 的流程就走完了。

这个流程中，只有 CQRS 的 Commond，并没有 Query，也没有 ES、Saga 的概念，主要是它们太深奥了，我搞不来。 只是一个简单的示例，发消息的业务含义所表达的可能不是很准确，本来是想用用户注册、订单提交业务示例，但还是想想用发消息进行尝试下，除去 EventBus 的实现有问题，CQRS 的简化版基本上都能表现出来了。

另外，从简单分层架构改造成 CQRS 确实有很多挑战，但有时候想想，领域模型都设计的有问题，那用什么架构实现都毫无意义，如果在现有的项目中，你发现经典分层架构实现起来有很多别扭的地方，比如 Domain 引用了 DTO，你可以尝试先把 Repositories 进行分离下，创建一个 Query 项目，把一些无业务逻辑的查询发到里面（主要是应用层调用的），这样使 Repositories 更加简化，如果可以简化成只有一个 GetById 方法，那么就达到 CQRS 的标准了，因为 Repositories 的接口定义在领域层，因为 Query 项目的分离，所以，Domain 就可以去除 DTO 的引用了，应用层也就直接调用 Query，这只是一个中和方案。

领域模型需要一点一滴设计，架构也需要一点一滴设计，但后者需要建立在前者的基础上。

一个对我非常有帮助的 CQRS 系列（初级）：

CQRS实践(1): 什么是CQRS

CQRS实践(2): Command的实现

CQRS实践(3): Command执行结果的返回

CQRS实践(4): 领域事件