基于“事件”驱动的领域驱动设计（DDD）框架分析

 

在介绍我设计的框架之前，我想先探讨一下以往我们都是如何思考设计OO的系统的。大家都知道，真正的对象应该是不仅有属性，而且有行为的。并且大家也有另外一个共识，那就是为了完成某个任务，各个对象应该会相互协作共同完成这个任务。之前我们在设计一个系统时，往往会先设计好各个对象，明确他们的职责，在这个过程中，还会考虑如何建立对象之间的关系（依赖、关联、聚合、组合），在这些关系的影响下，我们会认为对象之间应该有主从关系、依赖关系，等等。然后我们所做的这些设计最终的目的是为了能让对象之间能够通过相互协作来共同完成某个任务。这种方式最核心的设计特色是，我们会通过”对象引用“的方式来实现对象之间的各种关系。这种方式很好，并且我们也已经完全习惯了从对象的职责以及它们之间的关系的角度去设计对象。但这仅仅体现了一个哲学思想，那就是“物体之间通过直接作用完成某个任务”。

 

我觉得任何两个对象之间的交互有两种形式：1）直接作用，即对象A引用一个对象B，然后A调用B提供的某个方法，以此来完成两个对象之间的协作；2）间接作用，对象A不引用对象B，仅仅包含了一个对象B的唯一标识，当它要和对象B协作时，会发送一个消息给对象B，然后对象B收到该消息后做出响应，从而实现两个对象之间的协作；不管是哪种方式，他们最终的效果是一致的，都可以实现两个对象之间的交互并最终完成某个任务。那么这两种方式各自的优缺点在哪里呢？我个人觉得对于对象引用的方式，其好处就是简单、直观、容易理解，很符合我们平时的设计习惯。但坏处是什么呢？我个人觉得这种方式是形成对象耦合的根本原因，对象A对对象B存在了紧密的耦合，也许你会说，在间接作用的方式下，对象A不也会保留一个对象B的唯一标识吗？没错，但要知道保留引用和保留唯一标识的耦合强度是不一样的。前者的耦合强度更大，因为持有另外一个对象的引用就意味着可以直接操作该对象，而仅仅持有另外一个对象的唯一标识则不行，必须先根据该唯一标识获取另外一个对象，然后再操作它。而对于发送接受消息的方式，它的好处和坏处是什么呢？其实正好和前者相反，即不简单、不直观、不容易理解，容易让大家觉得有过度设计的嫌疑，而好处则是能够将两个对象之间的耦合度降到最低。

 

好了，有了前面这些介绍之后，我想可以引出我所设计的这个框架的设计思想了。

 

既然在对象直接作用的思路下设计软件的各种原则、模式，以及各种最佳实践已经很多了，如SOLID五大设计原则、GRASP九大OO设计原则、Gof的23种设计模式、各种更大的模式如MVC、MVP、MVVM，等等。所以，我也就不用去费功夫去研究了，直接利用前辈的研究成果就行了。但我发现在对象间接作用的思路下设计软件的各种原则或框架似乎还不够多。当然也有很多大家都很熟悉了，比如Observer设计模式，按照这个设计模式设计出来的.NET框架中的事件和委托的机制，还有比如一些第三方的开源框架如事件总线，事件驱动架构，等等。

 

思考到这里，再结合自己最近不断学习DDD的背景下，我脑子里有了一个奇特的想法！那就是：是否可以搞一个事件驱动的领域模型实现框架从而可以让我们从消息和行为的角度去设计对象呢？

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

1. 领域服务：这个元素和Evans提到的领域服务一致，主要目的也是用来完成单个领域对象不能完成的职责，如银行转账操作；
2. 领域对象：这个元素和Evans提到的Entity很类似，也有一个唯一标识，但和Evans中的概念也有不同的地方。比如Evans中的Entity为了保持领域模型的完整性，有聚合的概念，即Aggregate。另外还有值对象的概念，即Value Object。但在我的设计中，领域模型中的所有的对象都是平等的，没有任何聚合或关联的概念，也没有值对象的概念。所有的领域对象都通过事件来进行交互协作，从而达到完成各种任务的目的。
3. 领域事件：这个元素在整个领域模型中最重要，就好比是人体的血液或神经。它是领域模型内部各个领域对象之间通信以及领域模型和外部通信时传递的信息的载体。通过领域事件，我们可以“串”连任何两个领域对象，从而达到让他们相互协作的目的。所谓的串联就是，一个对象发出消息，另外一个对象接收消息并做出正确响应。值得一提的是，我这里提到的事件不仅仅是通知别人发生了什么，而是泛指所有可能的通信情况。比如告诉别人我要什么（我想干什么），告诉别人我将要做什么，等等。也就是说，事件有可能带有一定的目的性，即有可能会指定应该由哪个对象去响应该事件。也许在你看来这已经不是标准的事件了，因为标准的事件应该是不可能知道会由哪些人回去响应该事件的。没错，它就是一个不标准的事件。我前面已经提到了，我这里的事件指对象之间通信的载体。而通信的情况是非常多的，肯定不只局限于告诉别人我发生了什么，还有非常多其他的情况。最后还有一点需要特别指出的是，事件发出去并响应后，有可能会有响应结果。关于这个问题，一般有两个实现方式：利用事件的回调函数实现；让事件响应函数提供返回值，然后在事件完全响应完成后，从事件对象中取出可能的返回值。我认为这两种方式都可以，我的框架采用的是后者。
4. 中央事件处理器：这个元素只做一件事情，那就是处理某个传进来的事件。怎么处理？就是根据当前事件获取所有可能的响应者，然后调用每个响应者的响应函数执行每个响应。

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