领域驱动设计

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

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

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

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

关联尽量保持单向的关联

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

实体是领域中需要唯一标识的领域概念

区分两个实体，如果唯一标识不一样，那么即便实体的其他所有
属性都一样，也认为他们是两个不同的实体。

实体有生命周期，可能会被持久化到数据库，因此，不为实体定义一种可以唯一区分的标识，就无法区分到底哪个是实体

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

领域中，并不是每个事物都必须有一个唯一标识

如果两个对象的所有属性的值都相同的我们认为他们是同一个对象的话，就可以把这种对象设计为
值对象。

值对象另一个明显的特征是不可变，所有属性都是只读的

应该给值对象设计的尽量简单，不要引用很多其他对象

当你要修改Customer的Address对象引用时，不是通过Customer.Address.Street这样
的方式来实现，因为值对象是只读的，它是一个完整的不可分割的整体。我们可以这样做
Customer.Address = new Address(…);

领域中的一些概念不适合建模为对象，即归类到实体对象或值对象，因为他们本质上就是些操作，而不是事物

这些操作往往涉及多个领域对象，并且需要协调这些领域对象共同完成这个操作或动作。

如果强行将操作分配给任何一个对象，则被分配的对象就是承担一些不该承担的职责，从而导致对象的职责不明确

基于类的面向对象语言规定任何属性或行为都必须放在对象里面。所以我们需要寻找一种新的模式来表示这种
跨多个对象的操作

DDD认为服务是一个很自然的范式用来对应这种跨多个对象的操作，所以就有了领域服务模式，
和领域对象不同，领域服务是以动词开头来命名，如资金转帐服务可以命名为MoneyTransferService

也可以把服务理解为对象，但这和一般意义上的对象有区别，一般的领域对象都是有状态和行为的，而领域服务没有
状态只有行为，领域服务是无状态的，存在的意义就是协调领域对象共同完成某个操作。所有状态都保存在
相应的领域对象中。

模型（实体）与服务（场景）是对领域的一种划分，模型关注领域的个体行为，场景关注领域的群体行为，
模型关注领域的静态结构，场景关注领域的动态功能，这也符合现实中出现的各种现象，有动有静，有独立又协作。

领域服务另一个重要功能：避免领域逻辑泄漏到应用层。因为如果没有领域服务，那么应用层会直接调用领域对象
完成本该属于领域服务该做的操作，这样以来，领域层可能会把一部分领域知识泄漏到应用层，因为应用层需要了解每个
领域对象的业务功能，具有哪些信息，以及可能会与哪些领域对象交互，因此，引入领域服务可以有效防止领域层的逻辑泄漏到
应用层，对于应用层来说，从可理解的角度来讲，通过调用领域服务提供的简单易懂但意义明确的接口肯定比直接操作领域对象
容易。这里也可以看到领域服务具有Facade功能。

软件中一般有三种服务：
  应用层服务，领域服务，基础服务

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

聚合特点

如何识别聚合以及聚合根

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

仓储里面存放的对象一定是聚合，原因是之前提到的领域模型中是以聚合的概念区划分边界的，事实上我们把整个聚合看成一个整体概念，要么一起被
取出来，要么一起被删除，我们永远不会单独对某个聚合内的子对象进行单独查询或做更新操作，因此，我们只对聚合设计仓储。

仓储还有一个重要的特征就是分为仓储定义部分和仓储实现部分，在领域模型中我们定义仓储的接口，而在基础设施层实现具体的仓储。这样做的原因：
仓储背后的实现都是在和数据库打交道，我们又不希望客户（如应用层）把重点放在如何从数据库获取数据的问题上，因为这样会导致（应用层）代码混乱，
很可能会因此忽略了领域模型的存在，所以我们需要提供一个简单明了的接口，供客户使用，确保客户以最简单的方式获取领域对象，从而让他专心的不会被
什么数据访问代码打扰的情况下协调领域对象完成业务逻辑。这种痛殴接口来隔离封装变化的做法很常见，由于客户面对的是抽象的接口并不是具体的实现，所以我们可以随时替换仓储的真正实现。

尽管仓储可以像集合一样在内存中管理对象，但是仓储并不负责事务处理，一般事务处理会交给一个“工作单元”

对于修改领域对象的情况，通过仓储获取领域对象，调用领域对象相关业务方法以完成业务逻辑处理

对于新增领域对象的情况，通过构造函数或工厂创建出领域对象，如果需要还可以继续对该新创建的
领域对象做一些操作，然后把该新创建的领域对象添加到仓储中

对于删除领域对象的情况，可以先把领域对象从仓储中取出来，然后将其从仓储中删除，也可以直接
传递一个要删除的领域对象唯一标识给仓储通知其移除该唯一标识对应的领域对象。

如果一个业务逻辑涉及到多个领域对象，则调用领域层中的相关领域服务完成操作

注意：以上所说的所有领域对象都是指聚合根，另外在应用层需要获取仓储接口以及领域服务接口时，
都可以通过IOC容器获取，最后通知工作单元提交事务从而将所有相关的领域对象的状态以事务的方式持久化
到数据库中。

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

不基于快照：仓储的相关更新或新增或删除接口被调用时，仓储通知工作单元某个对象被新增了或更新了或删除了。这样工作单元再做数据持久化时也同样知道需要持久化哪些对象，这种方法理论上不需要ORM框架支持，对领域模型也没有侵入性，同时也很好的支持工作单元的模式。

不基于快照，也不用仓储告诉工作单元数据更改了：而是采用AOP的思想，采用透明代理的方式进行一个拦截，在Hibernate中，属性通常要被声明为virtual的，一个原因就是NHibernate会生成一个透明代理，用于拦截对象的属性被修改时，自动通知工作单元对象的状态被更新了。这样工作单元也同样知道需要持久化哪些对象了。这种方法对领域模型的倾入性不大，并且能很好的支持工作单元模式，如果用NHibernate作为ORM，这种方法用的比较多；

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

概念：CQRS是一种架构体系模式，能够使改变模型的状态命令和模型状态的查询实现
分离。

背景问题：在以前的管理系统中，命令和查询通常使用的是数据访问层中Responsibility中的实体对象（这些
对象时对DB中表的映射），这些实体有可能是SQL Server中的一行数据或者多个表。

通常对DB执行增、删、改、查都是针对系统实体对象，如通过数据访问层获取数据，然后通过数据传输对象DTO
传给表现层，或者用户更新数据，通过DTO对象将数据传给Model，然后通过数据访问层写回数据库，系统中所有交互
都是和查询和存储有关，可以认为是数据驱动的。

传统的CRUD存在一些问题：
 1. 使用同一个对象实体来进行数据库读写可能会太粗糙，大多数情况下，编辑的时候只需要更新个别字短，但是却需要将整个
对象传进去，有些字段不需要更新，查询的时候在表现层可能只需要个别字短，但是需要查询和返回整个实体对象。
  
 2. 使用同一实体对象对同一数据进行读写操作的是欧，可能会遇到资源竞争，经常要处理锁的问题，写入数据的时候，需要加锁，
读取数据的时候需要判断是否允许藏独。
 
 3. 同步的，直接与数据库进行交互在大数据量同时访问的情况下可能会影响性能和响应性，并且可能产生性能瓶颈

 4.  由于对于同一实体会在读写操作中用到，所以对于安全和权限的管理比较复杂。

解决方法：经常用到对数据库进行读写分离，让猪数据库处理事务性的增、删、改，从数据库处理查询。数据库复制被用来将事务性操作导致的
变更同步到集群中的从数据库。这是从DB角度处理了读写分离，但是从业务上将读写分离，就需要用到接下来的命令查询职责分离模式。

什么是CQRS：基本思想在于，任何一个对象的方法可以分为两大类：
 1. 命令：不返回任何结果，但会改变对象状态
 2. 查询：返回结果，但是不会改变对象状态，对系统没有副作用。

 操作和查询分离使得我们能够更好的把握对象的细节，更好的理解哪些操作会改变，当然CQS也有一些缺点，比如代码需要处理多线程情况。

 CQRS使用分离的接口将数据查询操作和数据修改操作分离，意味着在查询和更新过程中使用的数据模型也是不一样的。 
 主数据库处理CUD，从数据库处理R，从库的结构可以和主库的结构完全一样，也可以不一样，从库主要用来进行只读的查询操作。数量上，从库
的个数也可以根据查询的规模进行扩展，业务逻辑上，也可以根据专题从主库中划分不同的从库，从库也可以实现成ReportingDataBase，根据查询的
业务需求，从主库中抽取一些必要的数据生成一系列查询报表来存储。

CQRS与EventSourcing 的关系： 在CQRS中，查询方面，直接通过方法查询数据库，然后通过DTO将数据返回。操作方面，通过发送Command实现，
由CommandBus处理特定的Command，然后由Command将特定的Event发布到EventBus，然后EventBus使用特定的Handler来处理事件，执行一些诸如
修改，删除，更新等操作。这里，所有与Command相关的操作都通过Event来实现，这样我们可以通过记录Event来记录系统运行的历史记录，并且方便的
回滚到某一历史状态。EventSourcing就是用来进行存储和管理事件的。

CQRS架构实现

对于DDD中的聚合，不保存聚合的当前状态，而是保存对象上发生的每个事件，当要重建一个
聚合对象时，可以通过回溯这些事件（即让这些事件重新发生）来让对象恢复到某个特定的状态；
因为有时一个聚合可能会发生很多事件，所以如果每次要在重建对象时都从头回溯事件，会导致性能地下，
所以我们会在一定时候为聚合创建一个快照，这样就可以基于某个快照创建聚合对象。