基于“事件”驱动的领域驱动设计(DDD)框架分析及Demo演示

1、从去年 10月份开始,学了几个月的领域驱动设计(Domain Driven Design,简称 DDD 。 主要是学习领域驱动设计之父 Eric Evans的名著: Domain-driven design:领域驱动设 计 :软件核心复杂性应对之道,以及另外一本 Martin Flower的企业应用架构模式, 学习到了不少关于如何组织业务逻辑方面的知识。 另外, 在这个过程中也接触到了一些开源 的架构和一些很好的思想。如:命令查询职责分离(Command Query Responsibility Segregation ,简称 CQRS ,事件驱动架构(Event Driven Archite

2、cture,简称 EDA ,以 及四色原型和 DCI 架构,等等。前面这些知识对我来说是非常宝贵的财富,可以说我能进 淘宝,很大程度上也是因为我学习了前面这些知识的原因。在介绍我设计的框架之前, 我想先探讨一下以往我们都是如何思考设计 OO 的系统的。 大家 都知道, 真正的对象应该是不仅有属性, 而且有行为的。 并且大家也有另外一个共识, 那就 是为了完成某个任务, 各个对象应该会相互协作共同完成这个任务。 之前我们在设计一个系 统时, 往往会先设计好各个对象, 明确他们的职责, 在这个过程中, 还会考虑如何建立对象 之间的关系(依赖、关联、聚合、组合,在这些关系的影响下,我们会认为对象之间

3、应该 有主从关系、 依赖关系, 等等。 然后我们所做的这些设计最终的目的是为了能让对象之间能 够通过相互协作来共同完成某个任务。这种方式最核心的设计特色是,我们会通过 ” 对象引 用 “ 的方式来实现对象之间的各种关系。这种方式很好, 并且我们也已经完全习惯了从对象 的职责以及它们之间的关系的角度去设计对象 。但这仅仅体现了一个哲学思想,那就是 “ 物 体之间通过直接作用完成某个任务 ” 。我觉得任何两个对象之间的交互有两种形式:1 直接作用 ,即对象 A 引用一个对象 B ,然 后 A 调用 B 提供的某个方法,以此来完成两个对象之间的协作; 2 间接作用 ,对象 A 不 引用对象 B ,仅

4、仅包含了一个对象 B 的唯一标识,当它要和对象 B 协作时,会发送一个消 息给对象 B ,然后对象 B 收到该消息后做出响应,从而实现两个对象之间的协作;不管是 哪种方式, 他们最终的效果是一致的, 都可以实现两个对象之间的交互并最终完成某个任务。 那么这两种方式各自的优缺点在哪里呢?我个人觉得对于对象引用的方式,其好处就是简 单、 直观、 容易理解, 很符合我们平时的设计习惯。 但坏处是什么呢?我个人觉得这种方式 是形成对象耦合的根本原因,对象 A 对对象 B 存在了紧密的耦合,也许你会说,在间接作 用的方式下,对象 A 不也会保留一个对象 B 的唯一标识吗?没错,但要知道保留引用和保 留唯

5、一标识的耦合强度是不一样的。 前者的耦合强度更大, 因为持有另外一个对象的引用就 意味着可以直接操作该对象, 而仅仅持有另外一个对象的唯一标识 则不行, 必须先根据该唯一标识获取另外一个对象, 然后再操作它。 而对于发送接受消息的 方式,它的好处和坏处是什么呢?其实正好和前者相反,即不简单、不直观、不容易理解, 容易让大家觉得有过度设计的嫌疑,而好处则是能够将两个对象之间的耦合度降到最低。好了,有了前面这些介绍之后,我想可以引出我所设计的这个框架的设计思想了。既然在对象直接作用的思路下设计软件的各种原则、模式,以及各种最佳实践已经很多了, 如 SOLID 五大设计原则、 GRASP 九大 OO

6、 设计原则、 Gof 的 23种设计模式、各种更大的 模式如 MVC 、 MVP 、 MVVM ,等等。所以,我也就不用去费功夫去研究了,直接利用前辈 的研究成果就行了。 但我发现在对象间接作用的思路下设计软件的各种原则或框架似乎还不 够多。当然也有很多大家都很熟悉了,比如 Observer 设计模式,按照这个设计模式设计出来的 .NET 框架中的事件和委托的机制,还有比如一些第三方的开源框架如事件总线,事件 驱动架构,等等。思考到这里,再结合自己最近不断学习 DDD 的背景下,我脑子里有了一个奇特的想法!那 就是:是否可以搞一个 事件驱动的领域模型实现框架 从而可以让我们从消息和行为的角度去

7、 设计对象呢?有了这个框架,我们可以:1通过消息实现领域模型中各个领域对象之间的交互,或者说 是通信及协作; 2通过消息实现领域模型和外界的交互,如领域模型的使用者和领域模型 之间的交互, 一般这个使用者是应用层; 还有比如领域模型和数据持久层的交互。 带着这个 问题, 我试图去寻找目前已有的框架来实现我的想法, 但遗憾的是, 我找不到, 所以只能自 己开发。 想到这里, 我其实挺担心的, 因为我很有可能已经走火入魔了, 因为我要走的设计 道路很可能是个死胡同或不归路, 或者说不是一条真正能很好的解决软件设计的路, 不然我 怎么会找不到这样的框架呢?但不管怎样, 还是先试试再说吧! 反正我的大

8、脑放在那里不用 也是浪费。就这样,带着这样的目标和思路,我开始一步步设计我的框架了。经过了三个月的设计、编码、测试、分享、讨论、重构的循环过程。到目前为止,总算初步 实现了自己当初的目标, 现在唯一差的就是在真正的实际项目中使用了。 但幸好已经写了两 个不同层次的 Demo 用来验证我的框架了。该 Demo 包含了框架的源代码和 Demo 文件,基于 VS2010开发,因为需要用到 .NET4.0中的一些特性, 如逆变和协变。 源代码打开后, EventBasedDDDExample.PresentationLayer 是启动项目,直接 F5就可以运行。 该 Demo 为了重点突出领域模型的设

9、计,特意采用内存 作为数据持久层,去掉了应用层,并且用控制台应用程序作为 UI 层,这样就方便大家运行 Demo 。该项目包含了四个演示的例子,前面两个例子演示了如何利用我的框架实现特定的 业务场景(一个是银行转账的例子,另一个是论坛中发帖发回复删除回复的例子。下面介绍一下我的框架的设计思想:领域模型的组成元素:领域服务(Domain Service +领域对象(Domain Object +领域事 件(Domain Event +中央事件处理器(Event Processer。1. 领域服务:这个元素和 Evans 提到的领域服务一致,主要目的也是用来完成单个领 域对象不能完成的职责,如银行

10、转账操作;2. 领域对象:这个元素和 Evans 提到的 Entity 很类似, 也有一个唯一标识, 但和 Evans 中的概念也有不同的地方。 比如 Evans 中的 Entity 为了保持领域模型的完整性, 有 聚合的概念, 即 Aggregate 。 另外还有值对象的概念, 即 Value Object。 但在我的设 计中,领域模型中的所有的对象都是平等的,没有任何聚合或关联的概念,也没有 值对象的概念。所有的领域对象都通过事件来进行交互协作,从而达到完成各种任 务的目的。3. 领域事件:这个元素在整个领域模型中最重要,就好比是人体的血液或神经。它是 领域模型内部各个领域对象之间通信以及

11、领域模型和外部通信时传递的信息的载 体。通过领域事件,我们可以 “ 串 ” 连任何两个领域对象,从而达到让他们相互协作 的目的。所谓的串联就是,一个对象发出消息,另外一个对象接收消息并做出正确 响应。值得一提的是,我这里提到的事件不仅仅是通知别人发生了什么,而是泛指 所有可能的通信情况。比如告诉别人我要什么(我想干什么,告诉别人我将要做 什么,等等。也就是说,事件有可能带有一定的目的性,即有可能会指定应该由哪 个对象去响应该事件。也许在你看来这已经不是标准的事件了,因为标准的事件应 该是不可能知道会由哪些人回去响应该事件的。没错,它就是一个不标准的事件。 我前面已经提到了,我这里的事件指对象之

12、间通信的载体。而通信的情况是非常多 的,肯定不只局限于告诉别人我发生了什么,还有非常多其他的情况。最后还有一 点需要特别指出的是, 事件发出去并响应后, 有可能会有响应结果。 关于这个问题, 一般有两个实现方式:利用事件的回调函数实现;让事件响应函数提供返回值,然 后在事件完全响应完成后,从事件对象中取出可能的返回值。我认为这两种方式都 可以,我的框架采用的是后者。4. 中央事件处理器:这个元素只做一件事情,那就是处理某个传进来的事件。怎么处 理?就是根据当前事件获取所有可能的响应者,然后调用每个响应者的响应函数执 行每个响应。另外, 领域模型与外界如何交互呢?还是通过上面所提到的事件, 当外

13、界需要领域模型做什 么事情时, 就发送一个在领域模型中已经定义好的事件, 然后领域模型或其他人 (比如持久 层 就会响应该事件了。 当领域模型发生了什么或想要外界提供什么数据时, 也是通过发送 事件, 然后外界就会响应, 从而为领域模型提供必要的支持, 如持久化支持。 通过上面的分 析, 似乎可以看出我们已经找到银弹了, 即找到了一种单一的模式可以用来解决所有的对象 交互与协作的问题了?应该不是这样, 但我自己没发现不知道这种设计的问题出在哪里, 所 以非常期望大家能多给我些意见。 还是那句话, 我希望我们每个中国人都是一个不盲目相信 权威并敢于怀疑权威并能积极去思考和将自己的思考转化为生产力的人, 而不只是一个仅仅 会