DDD 学习笔记

DDD（Domain Driven Design）领域驱动模型，是一种处理高度复杂领域的设计思想，不是一种架构，而是一种架构设计方法论，是一种设计模式。

说白了就是，DDD就是以高内聚低耦合为目的，对软件系统进行模块化的一种思想。

基础概念——领域驱动设计

软件架构模式演进

这些年来随着设备和新技术的发展，软件的架构模式发生了很大的变化。软件架构模式大体来说经历了从单机、集中式到分布式微服务架构三个阶段的演进。随着分布式技术的快速兴起，我们已经进入到了微服务架构时代。

领域、子域、核心域、通用域和支撑域

领域

从广义上讲，领域具体指一种特定的范围或区域。DDD 的领域就是这个边界内要解决的业务问题域。

领域可以进一步划分为子领域。我们把划分出来的多个子领域称为子域，每个子域对应一个更小的问题域或更小的业务范围。

子域

在领域不断划分的过程中，领域会细分为不同的子域，子域可以根据自身重要性和功能属性划分为三类子域，它们分别是：核心域、通用域和支撑域。

核心域：决定产品和公司核心竞争力的子域是核心域，它是业务成功的主要因素和公司的核心竞争力。
通用域：没有太多个性化的诉求，同时被多个子域使用的通用功能子域是通用域。
支撑域：是必需的，但既不包含决定产品和公司核心竞争力的功能，也不包含通用功能的子域，是支撑域。

如何理解核心域、通用域和支撑域

这三类子域相较之下，核心域是最重要的。通用域和支撑域如果对应到企业系统，举例来说的话，通用域则是你需要用到的通用系统，比如认证、权限等等，这类应用很容易买到，没有企业特点限制，不需要做太多的定制化。而支撑域则具有企业特性，但不具有通用性，例如数据代码类的数据字典等系统。

很多公司的业务，表面看上去相似，但商业模式和战略方向是存在很大差异的，因此公司的关注点会不一样，在划分核心域、通用域和支撑域时，其结果也会出现非常大的差异。

商业模式的不同会导致核心域划分结果的不同。有的公司核心域可能在客户服务，有的可能在产品质量，有的可能在物流。在公司领域细分、建立领域模型和系统建设时，要结合公司战略重点和商业模式，找到核心域，且重点关注核心域。

总结

领域的核心思想就是将问题域逐级细分，来降低业务理解和系统实现的复杂度。通过领域细分，逐步缩小微服务需要解决的问题域，构建合适的领域模型，而领域模型映射成系统就是微服务了。

核心域、支撑域和通用域的主要目标是：通过领域划分，区分不同子域在公司内的不同功能属性和重要性，从而公司可对不同子域采取不同的资源投入和建设策略，其关注度也会不一样。

实体和值对象

实体

在 DDD 中有这样一类对象，它们拥有唯一标识符，且标识符在历经各种状态变更后仍能保持一致。对这些对象而言，重要的不是其属性，而是其延续性和标识，对象的延续性和标识会跨越甚至超出软件的生命周期。我们把这样的对象称为实体。

业务形态

在 DDD 不同的设计过程中，实体的形态是不同的。

在战略设计时，实体是领域模型的一个重要对象。领域模型中的实体是多个属性、操作或行为的载体。

在事件风暴中，我们可以根据命令、操作或者事件，找出产生这些行为的业务实体对象，进而按照一定的业务规则将依存度高和业务关联紧密的多个实体对象和值对象进行聚类，形成聚合。

可以这么理解，实体和值对象是组成领域模型的基础单元。

代码形态

在代码模型中，实体的表现形式是实体类（Entity），这个类包含了实体的属性和方法，通过这些方法实现实体自身的业务逻辑。

在 DDD 里，这些实体类通常采用充血模型，与这个实体相关的所有业务逻辑都在实体类的方法中实现，跨多个实体的领域逻辑则在领域服务中实现。

运行形态

实体以 DO（领域对象Domain Object）的形式存在，每个实体对象都有唯一的 ID。

我们可以对一个实体对象进行多次修改，修改后的数据和原来的数据可能会大不相同。但是，由于它们拥有相同的 ID，它们依然是同一个实体。

比如商品是商品上下文的一个实体，通过唯一的商品 ID 来标识，不管这个商品的数据如何变化，商品的 ID 一直保持不变，它始终是同一个商品。

数据库形态

与传统数据模型设计优先不同，DDD 是先构建领域模型，针对实际业务场景构建实体对象和行为，再将实体对象映射到数据持久化对象。

在领域模型映射到数据模型时，一个实体可能对应 0 个、1个或者多个数据库持久化对象。大多数情况下实体与持久化对象是一对一。在某些场景中，有些实体只是暂驻静态内存的一个运行态实体，它不需要持久化。比如，基于多个价格配置数据计算后生成的折扣实体。

而在有些复杂场景下，实体与持久化对象则可能是一对多或者多对一的关系。比如，用户 user 与角色 role两个持久化对象可生成权限实体，一个实体对应两个持久化对象，这是一对多的场景。再比如，有些场景为了避免数据库的联表查询，提升系统性能，会将客户信息customer 和账户信息 account 两类数据保存到同一张数据库表中，客户和账户两个实体可根据需要从一个持久化对象中生成，这就是多对一的场景。

值对象

通过对象属性值来识别的对象，它将多个相关属性组合为一个概念整体。在 DDD 中用来描述领域的特定方面，并且是一个没有标识符的对象，叫作值对象。

也就说，值对象描述了领域中的一件东西，这个东西是不可变的，它将不同的相关属性组合成了一个概念整体。当度量和描述改变时，可以用另外一个值对象予以替换。它可以和其它值对象进行相等性比较，且不会对协作对象造成副作用。

简单来说，值对象本质上就是一个集。那这个集合里面有什么呢？若干个用于描述目的、具有整体概念和不可修改的属性。那这个集合存在的意义又是什么？在领域建模的过程中，值对象可以保证属性归类的清晰和概念的完整性，避免属性零碎。

举个例子，人员实体原本包括：姓名、年龄、性别以及人员所在的省、市、县和街道等属性。现在，我们可以将“省、市、县和街道等属性”拿出来构成一个“地址属性集合”，这个集合就是值对象了。

业务形态

值对象是 DDD 领域模型中的一个基础对象，它跟实体一样都来源于事件风暴所构建的领域模型，都包含了若干个属性，它与实体一起构成聚合。

本质上，实体是看得到、摸得着的实实在在的业务对象，实体具有业务属性、业务行为和业务逻辑。

而值对象只是若干个属性的集合，只有数据初始化操作和有限的不涉及修改数据的行为，基本不包含业务逻辑。

值对象的属性集虽然在物理上独立出来了，但在逻辑上它仍然是实体属性的一部分，用于描述实体的特征。

代码形态

如果值对象是单一属性，则直接定义为实体类的属性
如果值对象是属性集合，则把它设计为 Class 类，Class 将具有整体概念的多个属性归集到属性集合，这样的值对象没有 ID，会被实体整体引用。

运行形态

实体实例化后的 DO 对象的业务属性和业务行为非常丰富，但值对象实例化的对象则相对简单和乏味。除了值对象数据初始化和整体替换的行为外，其它业务行为就很少了。

值对象嵌入到实体的话，有这样两种不同的数据格式，也可以说是两种方式，分别是属性嵌入的方式和序列化大对象的方式。

引用单一属性的值对象或只有一条记录的多属性值对象的实体，可以采用属性嵌入的方式嵌入。

引用一条或多条记录的多属性值对象的实体，可以采用序列化大对象的方式嵌入。

比如，人员实体可以有多个通讯地址，多个地址序列化后可以嵌入人员的地址属性。值对象创建后就不允许修改了，只能用另外一个值对象来整体替换。

数据库形态

DDD 引入值对象是希望实现从“数据建模为中心”向“领域建模为中心”转变，减少数据库表的数量和表与表之间复杂的依赖关系，尽可能地简化数据库设计，提升数据库性能。

在领域建模时，我们可以把地址作为值对象，人员作为实体，这样就可以保留地址的业务涵义和概念完整性。

而在数据建模时，我们可以将地址的属性值嵌入人员实体数据库表中，只创建人员数据库表。这样既可以兼顾业务含义和表达，又不增加数据库的复杂度。

优势和局限

值对象是一把双刃剑，它的优势是可以简化数据库设计，提升数据库性能。

值对象采用序列化大对象的方法简化了数据库设计，减少了实体表的数量，可以简单、清晰地表达业务概念。这种设计方式虽然降低了数据库设计的复杂度，但却无法满足基于值对象的快速查询，会导致搜索值对象属性值变得异常困难。

值对象采用属性嵌入的方法提升了数据库的性能，但如果实体引用的值对象过多，则会导致实体堆积一堆缺乏概念完整性的属性，这样值对象就会失去业务涵义，操作起来也不方便。

实体和值对象的关系

我们可以看出，同样的对象在不同的场景下，可能会设计出不同的结果。

有些场景中，地址会被某一实体引用，它只承担描述实体的作用，并且它的值只能整体替换，这时候你就可以将地址设计为值对象，比如收货地址。

而在某些业务场景中，地址会被经常修改，地址是作为一个独立对象存在的，这时候它应该设计为实体，比如行政区划中的地址信息维护。

聚合

在事件风暴中，我们会根据一些业务操作和行为找出实体（Entity）或值对象（ValueObject），进而将业务关联紧密的实体和值对象进行组合，构成聚合，再根据业务语义将多个聚合划定到同一个限界上下文（Bounded Context）中，并在限界上下文内完成领域建模。

聚合

举个例子。社会是由一个个的个体组成的，象征着我们每一个人。随着社会的发展，慢慢出现了社团、机构、部门等组织，我们开始从个人变成了组织的一员，大家可以协同一致的工作，朝着一个最大的目标前进，发挥出更大的力量。

领域模型内的实体和值对象就好比个体，而能让实体和值对象协同工作的组织就是聚合，它用来确保这些领域对象在实现共同的业务逻辑时，能保证数据的一致性。

可以这么理解，聚合就是由业务和逻辑紧密关联的实体和值对象组合而成的，聚合是数据修改和持久化的基本单元，每一个聚合对应一个仓储，实现数据的持久化。

聚合有一个聚合根和上下文边界，这个边界根据业务单一职责和高内聚原则，定义了聚合内部应该包含哪些实体和值对象，而聚合之间的边界是松耦合的。按照这种方式设计出来的微服务很自然就是“高内聚、低耦合”的。

聚合在 DDD 分层架构里属于领域层，领域层包含了多个聚合，共同实现核心业务逻辑。聚合内实体以充血模型实现个体业务能力，以及业务逻辑的高内聚。跨多个实体的业务逻辑通过领域服务来实现，跨多个聚合的业务逻辑通过应用服务来实现。比如有的业务场景需要同一个聚合的 A 和 B 两个实体来共同完成，我们就可以将这段业务逻辑用领域服务来实现；而有的业务逻辑需要聚合 C 和聚合 D 中的两个服务共同完成，这时你就可以用应用服务来组合这两个服务。

聚合根

聚合根的主要目的是为了避免由于复杂数据模型缺少统一的业务规则控制，而导致聚合、实体之间数据不一致性的问题。

传统数据模型中的每一个实体都是对等的，如果任由实体进行无控制地调用和数据修改，很可能会导致实体之间数据逻辑的不一致。而如果采用锁的方式则会增加软件的复杂度，也会降低系统的性能。

如果把聚合比作组织，那聚合根就是这个组织的负责人。聚合根也称为根实体，它不仅是实体，还是聚合的管理者。

首先它作为实体本身，拥有实体的属性和业务行为，实现自身的业务逻辑。

其次它作为聚合的管理者，在聚合内部负责协调实体和值对象按照固定的业务规则协同完成共同的业务逻辑。

最后在聚合之间，它还是聚合对外的接口人，以聚合根 ID 关联的方式接受外部任务和请求，在上下文内实现聚合之间的业务协同。也就是说，聚合之间通过聚合根 ID 关联引用，如果需要访问其它聚合的实体，就要先访问聚合根，再导航到聚合内部实体，外部对象不能直接访问聚合内实体。

领域模型

领域模型分为4大类：失血模型、贫血模型、充血模型、胀血模型

“血”指的是Domain Object的Domain层内容。

失血模型

Domain Object（领域对象）模型仅仅包含对象属性的定义和操作对象属性的getter/setter方法，所有的业务逻辑完全由Business Logic层(业务逻辑层)中的服务类来完成。这种类在java中叫POJO。

贫血模型

Domain Object（领域对象）模型包含对象属性的定义和操作对象属性的getter/setter方法并包含了对象的行为，但不包含依赖Dao层(持久层)的业务逻辑。这部分依赖于Dao层的业务逻辑将会放到Business Logic层（业务逻辑层）中的服务类来实现，组合逻辑也由服务类负责。

充血模型

Domain Object（领域对象）模型包含对象属性的定义和操作对象属性的getter/setter方法并包含了大多数相关的业务逻辑，也包含了依赖于持久层的业务逻辑，BusinessLogic层是很薄的一层，仅仅简单封装少量业务逻辑以及控制事务、权限逻辑等，不和DAO层打交道

涨血模型

Domain Object（领域对象）模型包含对象属性的定义和操作对象属性的getter/setter方法并包含了所有相关的的业务逻辑，也包含了不相关的其它应用逻辑（如授权、事务等）。胀血模型取消了BusinessLogic层(业务逻辑层)，只剩下Domain Object和DAO两层，在Domain Object的Domain Logic上面封装事务，授权逻辑等。

优缺点

模型	优点	缺点
失血模型	领域对象结构简单	业务代码逻辑肿胀，无法良好的应对复杂业务逻辑和场景
贫血模型	层次结构清楚，各层之间单向依赖	无法良好的应对非常复杂逻辑和场景
充血模型	包含了业务逻辑、权限逻辑等，不和DAO层打交道	无法复用/较为混乱
涨血模型	简化了代码分层结构	代码理解和维护困难

领域事件*

领域事件是领域模型中非常重要的一部分，用来表示领域中发生的事件。一个领域事件将导致进一步的业务操作，在实现业务解耦的同时，还有助于形成完整的业务闭环。

举例来说的话，领域事件可以是业务流程的一个步骤，比如投保业务缴费完成后，触发投保单转保单的动作；也可能是定时批处理过程中发生的事件，比如批处理生成季缴保费通知单，触发发送缴费邮件通知操作；或者一个事件发生后触发的后续动作，比如密码连续输错三次，触发锁定账户的动作。

微服务内的领域事件

当领域事件发生在微服务内的聚合之间，领域事件发生后完成事件实体构建和事件数据持久化，发布方聚合将事件发布到事件总线，订阅方接收事件数据完成后续业务操作。

微服务间领域事件

跨微服务的领域事件会在不同的限界上下文或领域模型之间实现业务协作，其主要目的是实现微服务解耦，减轻微服务之间实时服务访问的压力。

领域事件发生在微服务之间的场景比较多，事件处理的机制也更加复杂。跨微服务的事件可以推动业务流程或者数据在不同的子域或微服务间直接流转。

跨微服务的事件机制要总体考虑事件构建、发布和订阅、事件数据持久化、消息中间件，甚至事件数据持久化时还可能需要考虑引入分布式事务机制等。

微服务之间的访问也可以采用应用服务直接调用的方式，实现数据和服务的实时访问，弊端就是跨微服务的数据同时变更需要引入分布式事务，以确保数据的一致性。分布式事务机制会影响系统性能，增加微服务之间的耦合，所以我们还是要尽量避免使用分布式事务。

领域事件总体架构

事件构建和发布

事件基本属性至少包括：事件唯一标识、发生时间、事件类型和事件源，其中事件唯一标识应该是全局唯一的，以便事件能够无歧义地在多个限界上下文中传递。事件基本属性主要记录事件自身以及事件发生背景的数据。

事件中还有一项更重要，那就是业务属性，用于记录事件发生那一刻的业务数据，这些数据会随事件传输到订阅方，以开展下一步的业务操作。

事件基本属性和业务属性一起构成事件实体，事件实体依赖聚合根。领域事件发生后，事件中的业务数据不再修改，因此业务数据可以以序列化值对象的形式保存，这种存储格式在消息中间件中也比较容易解析和获取。

事件数据持久化

事件数据持久化可用于系统之间的数据对账，或者实现发布方和订阅方事件数据的审计。当遇到消息中间件、订阅方系统宕机或者网络中断，在问题解决后仍可继续后续业务流转，保证数据的一致性。

事件数据持久化有两种方案:

持久化到本地业务数据库的事件表中，利用本地事务保证业务和事件数据的一致性。
持久化到共享的事件数据库中。这里需要注意的是：业务数据库和事件数据库不在一个数据库中，它们的数据持久化操作会跨数据库，因此需要分布式事务机制来保证业务和事件数据的强一致性，结果就是会对系统性能造成一定的影响。

事件总线 (EventBus)

事件总线是实现微服务内聚合之间领域事件的重要组件，它提供事件分发和接收等服务。事件总线是进程内模型，它会在微服务内聚合之间遍历订阅者列表，采取同步或异步的模式传递数据。事件分发流程大致如下：

如果是微服务内的订阅者（其它聚合），则直接分发到指定订阅者；

如果是微服务外的订阅者，将事件数据保存到事件库（表）并异步发送到消息中间件；

如果同时存在微服务内和外订阅者，则先分发到内部订阅者，将事件消息保存到事件库（表），再异步发送到消息中间件。

消息中间件

跨微服务的领域事件大多会用到消息中间件，实现跨微服务的事件发布和订阅。

事件接收和处理

微服务订阅方在应用层采用监听机制，接收消息队列中的事件数据，完成事件数据的持久化后，就可以开始进一步的业务处理。领域事件处理可在领域服务中实现。

边界划分

我们可以用三步来划定领域模型和微服务的边界

第一步：在事件风暴中梳理业务过程中的用户操作、事件以及外部依赖关系等，根据这些要素梳理出领域实体等领域对象。

第二步：根据领域实体之间的业务关联性，将业务紧密相关的实体进行组合形成聚合，同时确定聚合中的聚合根、值对象和实体。在这个图里，聚合之间的边界是第一层边界，它们在同一个微服务实例中运行，这个边界是逻辑边界，所以用虚线表示。

第三步：根据业务及语义边界等因素，将一个或者多个聚合划定在一个限界上下文内，形成领域模型。在这个图里，限界上下文之间的边界是第二层边界，这一层边界可能就是未来微服务的边界，不同限界上下文内的领域逻辑被隔离在不同的微服务实例中运行，物理上相互隔离，所以是物理边界，边界之间用实线来表示。

DDD分层架构

用户接口层（interfaces）

它主要存放用户接口层与前端交互、展现数据相关的代码。前端应用通过这一层的接口，向应用服务获取展现所需的数据。这一层主要用来处理用户发送的Restful请求，解析用户输入的配置文件，并将数据传递给Application层。数据的组装、数据传输格式以及Facade接口等代码都会放在这一层目录里。

应用层（application）

它主要存放应用层服务组合和编排相关的代码。应用服务向下基于微服务内的领域服务或外部微服务的应用服务完成服务的编排和组合，向上为用户接口层提供各种应用数据展现支持服务。应用服务和事件等代码会放在这一层目录里。

此外，应用层也是微服务之间交互的通道，它可以调用其它微服务的应用服务，完成微服务之间的服务组合和编排。

在设计和开发时，不要将本该放在领域层的业务逻辑放到应用层中实现。因为庞大的应用层会使领域模型失焦，时间一长你的微服务就会演化为传统的三层架构，业务逻辑会变得混乱。

另外，应用服务是在应用层的，它负责服务的组合、编排和转发，负责处理业务用例的执行顺序以及结果的拼装，以粗粒度的服务通过 API 网关向前端发布。还有，应用服务还可以进行安全认证、权限校验、事务控制、发送或订阅领域事件等。

领域层（domain）

它主要存放领域层核心业务逻辑相关的代码。领域层可以包含多个聚合代码包，它们共同实现领域模型的核心业务逻辑。聚合以及聚合内的实体、方法、领域服务和事件等代码会放在这一层目录里。

领域模型的业务逻辑主要是由实体和领域服务来实现的，其中实体会采用充血模型来实现所有与之相关的业务功能。

其次，实体和领域对象在实现业务逻辑上不是同级的，当领域中的某些功能，单一实体（或者值对象）不能实现时，领域服务就会出马，它可以组合聚合内的多个实体（或者值对象），实现复杂的业务逻辑。

基础层（infrastructure）

它主要存放基础资源服务相关的代码，是贯穿所有层的，它的作用就是为其它各层提供通用的技术和基础服务，包括第三方工具、驱动、消息中间件、网关、文件、缓存以及数据库等。比较常见的功能还是提供数据库持久化。

架构原则

DDD 分层架构有一个重要的原则：每层只能与位于其下方的层发生耦合。

而架构根据耦合的紧密程度又可以分为两种：严格分层架构和松散分层架构。优化后的 DDD 分层架构模型就属于严格分层架构，任何层只能对位于其直接下方的层产生依赖。而传统的 DDD 分层架构则属于松散分层架构，它允许某层与其任意下方的层发生依赖。

DDD代码模型

包结构

结构1

plain
│
│    ├─interface        用户接口层 
│    │    ├─assembler       实现 DTO 与领域对象之间的相互转换和数据交换
│    │    ├─facade          提供较粗粒度的调用接口，将用户请求委派给一个或多个应用服务进行处理
│    │    └─dto             它是数据传输的载体，内部不存在任何业务逻辑
│    │ 
│    ├─application      应用层
│    │    ├─event           事件
│    │    │    ├─publish        事件发布相关代码
│    │    │    └─subscribe      事件订阅相关代码
│    │    └─service         应用服务，会对多个领域服务或外部应用服务进行封装、编排和组合，对外提供粗粒度的服务
│    │ 
│    ├─domain           领域层
│    │    ├─aggregate1      聚合1，聚合软件包的根目录，可以根据实际项目的聚合名称命名
│    │    │    ├─entity         实体，存放聚合根、实体、值对象以及工厂模式（Factory）相关代码
│    │    │    ├─event          事件，事件实体以及与事件活动相关的业务逻辑代码    
│    │    │    ├─repository     仓储，存放所在聚合的查询或持久化领域对象的代码，一个聚合对应一个仓储
│    │    │    │    ├─facade        仓储接口，封装仓储接口
│    │    │    │    └─persistence   仓储实现，存放仓储接口的实现代码
│    │    │    └─service        领域服务，一个领域服务是多个实体组合出来的一段业务逻辑
│    │    └─aggregate2      聚合2
│    │ 
│    ├─infrastructure   基础设施层
│    │    ├─config          主要存放配置相关代码
│    │    ├─util            主要存放平台、开发框架、消息、数据库、缓存、文件、总线、网关、第三方类库、通用算法等基础代码
│    │    │    ├─api
│    │    │    ├─driver
│    │    │    ├─eventbus
│    │    │    └─mq
│    │    │
│    │
│

结构2

plain
│
│    ├─interface        用户接口层 
│    │    ├─controller      控制器，对外提供（Restful）接口
│    │    ├─facade          外观模式，对外提供本地接口和dubbo接口
│    │    └─mq              mq消息，消费者消费外部mq消息
│    │ 
│    ├─application      应用层
│    │    ├─assembler       装配器
│    │    ├─dto             数据传输对象，xxxCommand/xxxQuery/xxxVo     
│    │    │    ├─command        接受增删改的参数
│    │    │    ├─query          接受查询的参数
│    │    │    └─vo             返回给前端的vo对象
│    │    ├─service         应用服务，负责领域的组合、编排、转发、转换和传递
│    │    └─listener        事件监听定义
│    │ 
│    ├─domain           领域层
│    │    ├─entity          领域实体
│    │    ├─valueobject     领域值对象
│    │    ├─service         领域服务
│    │    ├─repository      仓库接口，增删改的接口
│    │    ├─acl             防腐层接口
│    │    └─event           领域事件
│    │ 
│    ├─infrastructure   基础设施层
│    │    ├─converter       实体转换器
│    │    ├─repository      仓库
│    │    │    ├─impl           仓库实现
│    │    │    ├─mapper         mybatis mapper接口
│    │    │    └─po             数据库orm数据对象 
│    │    ├─ack             实体转换器
│    │    ├─mq              mq消息
│    │    ├─cache           缓存
│    │    └─util            工具类
│    │    
│

与MVC对比

MVC的开发模式：是数据驱动，自低向上的思想，关注数据。

DDD的开发模式：是领域驱动，自顶向下，关注业务活动。

CQRS

CQRS(Command Query Responsibility Segregation)是将Command(命令)与Query(查询)分离的一种模式。其基本思想在于：任何一个方法都可以拆分为命令和查询两部分

Command：不返回任何结果(void)，但会改变对象的状态。Command是引起数据变化操作的总称，一般会执行某个动作，如：新增，更新，删除等操作。操作都封装在Command中，用户提交Command到CommandBus，然后分发到对应的CommandHandler中执行。Command执行后通过Repository将数据持久化。事件源(Event source)CQRS，Command将特定的Event发送到EventBus，然后由特定的EventHandler处理。

Query：返回查询结果，不会对数据产生变化的操作，只是按照某些条件查找数据。基于Query条件，返回查询结果；为不同的场景定制不同的Facade。

数据类型转换

DTO（Data Transfer Object）：数据传输对象，主要用来做数据传输，比如：请求参数、响应结果等。
DO（Domain Object）：领域对象，主要用来做数据存储，比如：数据库表对应的实体类。
PO（Persistence Object）：持久化对象，主要用来做数据存储，比如：数据库表对应的实体类。
VO（Value Object）：值对象，主要用来做数据传输，比如：请求参数、响应结果等。
VO（View Object）：视图对象，特殊的DTO，主要作为视图层数据传输，比如：页面展示的数据。

参考文档