您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
CQRS体系结构模式实践案例:Tiny Library:领域仓储与事件存储
 
来源:来自网络 发布于: 2017-9-25
   次浏览      
 

领域仓储(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: }

2.整个Domain Model只有一个数据源:事件存储(Event Store),用来保存所有发生在聚合上的领域事件。这个Event Store具体如何设计,可以根据应用系统的需求来决定,但总归是非常的简单,甚至于仅用一张关系型数据库的数据表就可以实现。对于采用关系型数据库实现的事件存储,由于数据表数量很少,而且之间的关系变得非常简单,于是ORM就可以省略,直接采用Direct SQL实现;如果不采用关系型数据库作为事件存储,那可以选择的范围就更大了:各种NoSQL数据库、对象数据库、内存数据库等等。就关系型数据库而言,我们可以对事件存储所使用的数据表做如下的设计:

目前,Tiny Library CQRS赖以生存的开发框架Apworks,仅提供支持SQL Server的Event Store设计(Apworks当前版本:Alpha,v1.0.4016.23016)

3.如果事件存储采用的是关系型数据库,领域仓储对事件存储,原则上也只有类似如下两种操作:

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 . CreateOrUpdateSnapshot 方法进行定义的。在 Apworks . Events . Storage . SqlDomainEventStorage 类中,实现了这个方法,并指定每当第1000个领域事件发生时,对聚合做一次快照。如果你打算继续采用SQL Server作为事件存储,并打算重新定制快照策略,请新建一个类并继承Apworks . Events . Storage . SqlDomainEventStorage 类,然后重写 CreateOrUpdateSnapshot 方法;如果你打算采用其它的介质作为事件存储,则请自行实现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子目录中找到这个文件。

<?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上查看具体的代码实现。

   
次浏览       
相关文章

为什么要做持续部署?
剖析“持续交付”:五个核心实践
集成与构建指南
持续集成工具的选择-装载
 
相关文档

持续集成介绍
使用Hudson持续集成
持续集成之-依赖管理
IPD集成产品开发管理
相关课程

配置管理、日构建与持续集成
软件架构设计方法、案例与实践
单元测试、重构及持续集成
基于Android的单元、性能测试