基于事件驱动的DDD领域驱动设计框架分享(附源代码).pdf

基于事件驱动的 DDD 领域驱动设计框架分享（附源代码） 补充：现在再回过头来看这篇文章，感觉当初自己偏 激了，呵呵。不过没有以前的我，怎么会有现在的我和现 在的 enode 框架呢？发现自己进步了真好！从去年 10 月份 开始，学了几个月的领域驱动设计（ Domain Driven Design ，简称 DDD ）。主要是学习领域驱动设计之父 Eric Evans 的名著： 《Domain-driven design ：领域驱动设计 :软 件核心复杂性应对之道》 ，以及另外一本 Martin Flower 的 《企业应用架构模式》 ，学习到了不少关于如何组织业务逻 辑方面的知识。另外，在这个过程中也接触到了一些开源 的架构和一些很好的思想。如：命令查询职责分离 （Command Query Responsibility Segregation ，简称 CQRS），事件驱动架构（ Event Driven Architecture ，简称 EDA），以及四色原型和 DCI 架构，等等。前面这些知识对 我来说是非常宝贵的财富，可以说我能进淘宝，很大程度 上也是因为我学习了前面这些知识的原因。在介绍我设计 的框架之前，我想先探讨一下以往我们都是如何思考设计 OO 的系统的。大家都知道，真正的对象应该是不仅有属 性，而且有行为的。并且大家也有另外一个共识，那就是 为了完成某个任务，各个对象应该会相互协作共同完成这 个任务。之前我们在设计一个系统时，往往会先设计好各 个对象，明确他们的职责，在这个过程中，还会考虑如何 建立对象之间的关系（依赖、关联、聚合、组合） ，在这些 关系的影响下，我们会认为对象之间应该有主从关系、依 赖关系，等等。然后我们所做的这些设计最终的目的是为 了能让对象之间能够通过相互协作来共同完成某个任务。 这种方式最核心的设计特色是，我们会通过”对象引用“的方 式来实现对象之间的各种关系。这种方式很好，并且我们 也已经完全习惯了从对象的职责以及它们之间的关系的角 度去设计对象。但这仅仅体现了一个哲学思想，那就是“物 体之间通过直接作用完成某个任务”。 我觉得任何两个对象 之间的交互有两种形式： 1）直接作用，即对象 A 引用一个 对象 B，然后 A 调用 B 提供的某个方法，以此来完成两个 对象之间的协作； 2 ）间接作用，对象 A 不引用对象 B，仅 仅包含了一个对象 B 的唯一标识，当它要和对象 B 协作 时，会发送一个消息给对象 B，然后对象 B 收到该消息后做 出响应，从而实现两个对象之间的协作；不管是哪种方 式，他们最终的效果是一致的，都可以实现两个对象之间 的交互并最终完成某个任务。那么这两种方式各自的优缺 点在哪里呢？我个人觉得对于对象引用的方式，其好处就 是简单、直观、容易理解，很符合我们平时的设计习惯。 但坏处是什么呢？我个人觉得这种方式是形成对象耦合的 根本原因，对象 A 对对象 B 存在了紧密的耦合，也许你会 说，在间接作用的方式下，对象 A 不也会保留一个对象 B 的唯一标识吗？没错，但要知道保留引用和保留唯一标识 的耦合强度是不一样的。前者的耦合强度更大，因为持有 另外一个对象的引用就意味着可以直接操作该对象，而仅 仅持有另外一个对象的唯一标识则不行，必须先根据