领域仓储（Domain Repository）与事件存储（Event Store）是CQRS体系结构应用系统中C部分（Command部分）的重要组件。虽然都是存储机制，但两者有着本质的区别：领域仓储是属于领域层的，而事件仓储则是属于基础结构层的。领域模型产生事件，领域仓储负责保存、发布事件，并通过事件序列重塑领域模型。由于领域仓储的存在，使得“内存领域模型（In-memory Domain）”成为可能。

在上文中我已经对对象的状态做了一些介绍，通过这些介绍我们能够了解到，在应用系统中，是领域事件导致了对象状态的变化，于是，我们只需要把这些领域事件按顺序记录下来，我们就有能力将领域模型还原到任何一个时间点上。就以Tiny Library中的Reader聚合为例，当Reader刚刚被创建的时候，它的Name状态是空的，客户程序可以通过Reader实体的ChangeName方法来改变Name的状态。ChangeName方法会直接产生一个ReaderNameChangedEvent的领域事件，告知系统，现在发生了一件事情，这件事情将会改变Reader实体的状态。Reader实体获得了这个事件通知，就将Name状态设置为事件数据中的给定名称，同时，这个ReaderNameChangedEvent事件也被临时保存在了Reader实体中。

另一方面，当客户程序调用领域仓储来保存Reader时，仓储会将Reader中所有的领域事件读取出来，按照顺序逐个保存到事件存储中，与此同时，将这些事件发布到事件总线（Event Bus）上，以便同一系统的其它组件（比如Query Database）或者其它的系统能够接收到事件到达通知而做进一步的处理。

当客户程序需要通过领域仓储读取聚合时，领域仓储就会新建聚合，然后从事件存储中，以该聚合的聚合根的类型作为搜索条件，将领域事件按顺序读取出来并一个个地应用在这个新建的聚合上，聚合根实体一旦捕获到事件，就会按照事件的数据内容更新对应的状态，于是，聚合也就被恢复到了最后一次事件发生后的状态了。

这个过程很简单，通过上面的分析不难发现：

1. 由于查询部分的分离，领域仓储仅存两种操作：将聚合保存到事件存储以及从事件存储还原对象。与之对应的操作大致可以表示成下面的接口（该部分代码摘录自Apworks Application Development Framework）：

   1: public interface IDomainRepository : IUnitOfWork, IDisposable

   2: {

   3:     TAggregateRoot Get<TAggregateRoot>(long id)

   4:         where TAggregateRoot : class, ISourcedAggregateRoot, new();

   5:  

   6:     void Save<TAggregateRoot>(TAggregateRoot aggregateRoot)

   7:         where TAggregateRoot : class, ISourcedAggregateRoot, new();

   8: }

1. 整个Domain Model只有一个数据源：事件存储（Event Store），用来保存所有发生在聚合上的领域事件。这个Event Store具体如何设计，可以根据应用系统的需求来决定，但总归是非常的简单，甚至于仅用一张关系型数据库的数据表就可以实现。对于采用关系型数据库实现的事件存储，由于数据表数量很少，而且之间的关系变得非常简单，于是ORM就可以省略，直接采用Direct SQL实现；如果不采用关系型数据库作为事件存储，那可以选择的范围就更大了：各种NoSQL数据库、对象数据库、内存数据库等等。就关系型数据库而言，我们可以对事件存储所使用的数据表做如下的设计：
   
   目前，Tiny Library CQRS赖以生存的开发框架Apworks，仅提供支持SQL Server的Event Store设计（Apworks当前版本：Alpha，v1.0.4016.23016）
2. 如果事件存储采用的是关系型数据库，领域仓储对事件存储，原则上也只有类似如下两种操作：

   1: // 查询事件存储

   2: SELECT * FROM [Events] WHERE AggregateId=xxx ORDER BY Version

   3:  

   4: // 向事件存储保存事件

   5: INSERT INTO [Events] ([AggregateId], [Timestamp], [Version], [Data]) VALUES (...)

当然，在实际应用中，领域仓储与事件存储的实现并没有那么简单。原因可以通过如下几个疑问进行了解：

• 领域仓储的设计中，没有提到从事件存储中删除事件数据，时间一长，岂不是事件存储会变得很大？
  没错！领域仓储从来不会从事件存储中删除数据，即使是客户程序请求删除某个领域对象，这一操作也同样会产生一个事件（比如：ReaderDeletedEvent）并保存在事件存储中。这样做的理由来自于Event Sourcing所带来的一种数据分析与跟踪的可能性：Event Audit。它允许你将你的领域模型还原到任何时间点，然后通过事件重放（replay）来诊断你的模型数据。不仅如此，你还可以利用这些保存的数据重新搭建你的测试环境，用来对对象数据进行测试。当然，目前大部分系统可能用不到这样的Event Audit的功能，那么，在引入“快照”的情况下，你可以从事件存储数据库中定期地删除数据。然而，这是另外一种“退化”的CQRS设计，也同样是合理的，不过这不是我们讨论的范围。我们要讨论的是，时间一长，事件存储变得巨大怎么办？
  CQRS架构社区中有一句非常有意思的话，就是：Storage is cheap，data is valuable（存储是廉价的，而数据是有价值的）。通常，都是通过大容量存储备份以及数据归档来解决这样的问题：对于较早的事件数据，我们选用高速而昂贵的存储介质进行备份，而对于更早的事件数据，则可以采用低速而便宜的存储介质进行归档，综合采用两种不同的方案以使得事件存储端“性价比”达到最高。当然，这样的策略同样需要“快照”的支持
• 某些聚合的生命周期可能很长，于是就会在它们身上产生大量的事件数据，当领域仓储重建这些聚合的时候，需要把大量的事件依次地“应用”在这些聚合上，岂不是会花很多时间？
  在此，我们通过引入“快照”的概念来解决这个问题。在系统中，可以根据一定的“快照策略”来确定何时应该对聚合进行“快照”。每当这个快照策略的条件符合，系统就会对聚合做一次快照，并将快照数据记录在事件存储中。比如：我们可以指定，每n个事件发生时，就对聚合做一次快照，于是，当我们需要获得第n+3个事件发生时，该聚合的状态的时候，就只需要直接从事件存储中读取第n个事件发生时，聚合的快照，然后再依次将n+1、n+2、n+3个事件应用到聚合即可。这样就大大缩短了重建聚合所需的时间，也使得上面第一个问题中归档的实现成为可能
  在Apworks应用开发框架中，目前版本（Alpha，v1.0.4016.23016）对快照的支持是采用的GoF的memento模式，而对快照策略的支持就显得非常简单：仅仅是通过Apworks.Events.Storage.IDomainEventStorage.CanCreateOrUpdateSnapshot方法进行定义的。在Apworks.Events.Storage.SqlDomainEventStorage类中，实现了这个方法，并指定每当第1000个领域事件发生时，对聚合做一次快照。如果你打算继续采用SQL Server作为事件存储，并打算重新定制快照策略，请新建一个类并继承Apworks.Events.Storage.SqlDomainEventStorage类，然后重写CanCreateOrUpdateSnapshot方法；如果你打算采用其它的介质作为事件存储，则请自行实现Apworks.Events.Storage.IDomainEventStorage接口
• 在保存聚合的时候，领域仓储不仅需要将事件保存到事件存储，而且还需要将事件推送到事件总线上，这样做从技术上很难保证操作的原子性，换句话说，会不会造成数据的不一致性？
  是的，这就是所谓的“两次提交”（Two-Phase Commit, TPC）操作。在设计中应该避免TPC的出现，因为在两次提交之间会发生很多事情，如果不能保证操作的原子性，也就无法保证数据的一致性。对于CQRS体系结构的应用系统而言，这是致命的。目前在事件存储部分，避免TPC有两种方案：A.将事件存储整合到事件总线；B.将事件总线整合到事件存储。总之，思想只有一个：就是采用同一个持久化机制来整合存储部分与总线部分。有关TPC的深入研究，我会在后续的扩展话题中讨论。目前版本的Apworks（Alpha，v1.0.4016.23016）不提供对TPC的支持

现在，我们再来看看Tiny Library CQRS项目中，事件存储的实现方式。实际上，Tiny Library CQRS采用的是Apworks应用开发框架所提供的默认的事件存储机制：基于SQL Server的单表事件存储。表结构如下：

首先，领域仓储从聚合获得未保存（即未提交）事件，然后，使用指定的序列化方式，将事件序列化为二进制流，并保存到Apworks.Events.Storage.DomainEventDataObject对象中，这个对象其实是一个DTO，它可以被序列化/反序列化，也可以被序列化为Data Contract而通过WCF在网络上自由传输。Apworks的基础结构层会通过DomainEventDataObject的属性定义，并结合一个给定的Storage Mapping Schema（也就是TinyLibrary.Services.DomainEventStorageMappings.xml文件），将DomainEventDataObject的数据保存到上面的数据表里。

在此简单介绍一下这个Storage Mapping Schema。由于我们使用的是关系型数据库，为了解耦“数据对象/属性”与“数据表/字段”的匹配，Apworks引入了Storage Mapping Schema，这个文件有点像NHibernate中的Mapping XML，但比NHibernate的Mapping XML简单很多：它不支持对数据对象关系与表关系的映射，它不是一个ORM。在Storage Mapping Schema中，仅仅简单地定义了数据对象/数据表，以及对象属性/字段的映射关系，这是由于，CQRS体系结构从实现上降低了关系型数据库的地位，定义数据表及其之间的关系已经不那么重要了。这里我又可以给出两种方案：如果你仍然希望在事件存储部分采用关系型数据库，并打算去维护复杂的数据表关系，那么，你可以不选用Storage Mapping Schema，而采用ORM（比如NHibernate），此时，DomainEventDataObject就是ORM上的“实体”；如果你不打算采用关系型数据库，而选择对象数据库（比如：Db4O），那么，你也不需要去维护任何的Mapping XML，对象数据库会帮你打理好一切，这将大大提高系统性能。以下是Storage Mapping Schema的XSD结构，以供参考。该XSD文件已被包含在Apworks应用开发框架的安装包里，用户可以在Apworks安装目录的scripts子目录中找到这个文件。

   1: <?xml version="1.0" encoding="UTF-8"?>

   2: <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 

   3:            elementFormDefault="qualified" 

   4:            attributeFormDefault="unqualified">

   5:     <xs:element name="StorageMappingSchema">

   6:         <xs:annotation>

   7:             <xs:documentation/>

   8:         </xs:annotation>

   9:         <xs:complexType>

  10:             <xs:sequence minOccurs="0">

  11:                 <xs:element ref="DataTypes"/>

  12:             </xs:sequence>

  13:         </xs:complexType>

  14:     </xs:element>

  15:     <xs:element name="DataTypes">

  16:         <xs:complexType>

  17:             <xs:sequence minOccurs="0" maxOccurs="unbounded">

  18:                 <xs:element ref="DataType"/>

  19:             </xs:sequence>

  20:         </xs:complexType>

  21:     </xs:element>

  22:     <xs:element name="DataType">

  23:         <xs:complexType>

  24:             <xs:sequence minOccurs="0">

  25:                 <xs:element ref="Properties"/>

  26:             </xs:sequence>

  27:             <xs:attribute name="FullName" type="xs:string" use="required"/>

  28:             <xs:attribute name="MapTo" type="xs:string" use="required"/>

  29:         </xs:complexType>

  30:     </xs:element>

  31:     <xs:element name="Properties">

  32:         <xs:complexType>

  33:             <xs:sequence minOccurs="0" maxOccurs="unbounded">

  34:                 <xs:element ref="Property"/>

  35:             </xs:sequence>

  36:         </xs:complexType>

  37:     </xs:element>

  38:     <xs:element name="Property">

  39:         <xs:complexType>

  40:             <xs:attribute name="Name" type="xs:string" use="required"/>

  41:             <xs:attribute name="MapTo" type="xs:string" use="required"/>

  42:             <xs:attribute name="Identity" type="xs:boolean" use="optional"/>

  43:             <xs:attribute name="AutoGenerate" type="xs:boolean" use="optional"/>

  44:         </xs:complexType>

  45:     </xs:element>

  46: </xs:schema>

最后，在此给出Apworks应用开发框架中基于SQL Server的Event Store的类关系图，供大家参考。为了节省版面空间，此图中隐藏了类中的属性与方法定义，有兴趣的朋友可以到Apworks的站点http://apworks.codeplex.com上查看具体的代码实现。

在下一篇文章中，我将向大家介绍Tiny Library CQRS项目中，事件总线（Event Bus）与消息派送器（Message Dispatcher）的设计与实现，敬请期待！