浅谈“领域驱动设计”

作者：老王

Eric Evans所著的《领域驱动设计》（Domain-Driven Design：通常简称为“DDD”）一书可以说是经典中的经典，虽然“领域”的概念早就存在，但是直到这本书的出现，才让人们真正开始认真审视软件的构 建，相信你看了这本书后会真正体会领域的力量，也正是这个力量决定了软件最终的价值。

领域的含义：

简单的说，每个软件程序都会与其用户的活动或兴趣相关，其中使用程序的主要环境称为软件的“领域”。

领域中形形色色的业务逻辑构成了软件丰富多采的行为。举例来说，银行财务系统中，领域逻辑就包括了诸如开户，转帐等等操作。可能你会说，PHP程序 员很少会接触银行系统，这样的例子不够浅显，那我举一个更常见的例子，大凡程序员应该都接触过文章管理系统，它里面的置顶，加精等操作就是领域逻辑。这样 看来，似乎用例对应的动作都是领域逻辑了，但是答案是否定了，比如说，文章管理系统中保存文章往往就不是领域逻辑，因为它只是一个和持久化相关的动作而 已，是纯粹的技术实现，但是银行财务系统中的保存现金通常却被划为领域逻辑，因为它就是我们常说的存款，有明确的业务含义。看到这，似乎大家又有些 Faint了，这里给出一个判断是否是领域逻辑的原则：就是这个逻辑动作是否有明确的业务上的含义，或者说是否是业务相关的，而不仅仅是技术相关的。

只有将技术实现手段从领域问题中剥离才能保证领域本身的精炼，保证程序员可以把精力集中到领域问题本身上来，而不会满脑子都是技术实现手段。

领域的组成：

按照Eric的表述，通常将领域中的组成角色分为以下五种：

实体（Entity）：拥有唯一标识的对象。
值对象（Value Object）：没有唯一标识的对象。
工厂（Factory）：定义创建实体的方法。
仓储（Repository）：管理实体的集合并封装其持久化过程。
服务（Service）：实现不能指派或封装在一个单一对象上的操作。

领域的思考：

下面针对上面介绍的五种领域角色来逐一讨论。

实体的概念是比较好理解的，这样的例子很多，比如说每一个人都可以看作是一个“与众不同”的实体，我之所以用与众不同这个词是为了强调实体必须是能 够唯一标识出来的，即便是在我们看作长得一模一样的双胞胎，他们也是能更根据一些标识来区分开，比如指纹，可能你会抬杠，要是没有手的残疾人怎么办？那样 我们还可以使用DNA检测，当然，这些都是笑谈了，实际编程的时候，一般是使用一个自增数来作为标识，比如在MySQL数据库中保存实体的时候可以使用 anto_increment属性的自增字段。需要注意的是如果想判断两个实体是否相等，不能根据实体的属性来判断，必须绝对依赖实体的标识，十年前的你 和现在的你虽然在身高，体重，年龄等众多重要的属性中多或多或少的发生了变化，但你还是你，因为你的DNA不会因为这些属性的变化而变化。这些理解起来似 乎有些哲学的味道了。

值对象的含义，老实说相对实体来说比较模糊，很多人喜欢把数据传输对象也称为值对象（数据传输对象和我们这里说的值对象是有差别的）让人们对值对象 的理解产生过很多歧义，而且值对象的例子不如实体那么直接。从字面上来理解，值对象没有唯一标识，大多数情况下，值对象是不变的，所以系统不用实时的跟踪 他们，用的时候就实例化一个，不用的时候就销毁，但是，什么时候使用值对象？把哪些属性划为值对象？值对象的作用是什么？这些都是值得考虑的问题。通常来 说，当我们进行领域建模的时候，优先把唯一标识和经常用来检索对象的信息作为实体的属性，而其他信息根据相关性或者划分到其他实体中，或者划分为值对象， 举例来说：一个CMS系统中，对于文章实体而言，文章编号，文章标题等都应该作为文章实体的属性存在，而对于文章有效性期限的开始时间，结束时间两个信息 则应该被放在一个独立的值对象中，这其中，只有开始时间或结束时间，或者开始时间和结束时间同时都存在或不存在，会代表不同的逻辑意义，合理使用值对象， 既有利于屏蔽一些相关逻辑的复杂性，也可以保持实体对象的简洁。

工厂相对与前两者会好理解的多，毕竟从名字上就能体现出它的职责，那就是创建对象。既然是创建对象，那我们直接实例化一个不行么？简单的情况是可以 的，但是工厂往往会带来巨大的好处，简单的说就是屏蔽了创建对象的复杂性。领域创建对象强调的关联，一组相关的对象应该被看作一个整体，对于其中任何对象 的访问也应该从这个整体的“根”开始（通常整体中最重要的实体作为跟），所以复杂的关联必然会使创建过程同样复杂起来，那我们可不可以在“根”实体的构造 函数中完成对象的组装呢，简单的情况可以，复杂的不合适，比如说组装汽车，通常是在工厂里由组装工人和机器人来操作完成，如果我们在“跟”的构造函数里完 成组装，无异与在汽车里配备了组装工人和机器人，这当然是不必要的，汽车一旦组装出厂，就不需要组装工人和机器人了，此时再附带他们是一种累赘。

仓储的概念和一些人常说的数据访问对象（DAO）有些类似，但是并不等同，二者一个很大的不同是仓储有“根”的概念，而数据访问对象往往是按照数据 库的表来划分的。使用仓储主要是为了查询和持久化领域对象，而领域对象之间往往会有复杂的聚合关系，为了保证不变量，所以才引入根的概念，对领域对象中某 个子对象的访问必须通过根来导航。这样说可能不易理解，我举一个简单的例子：轿车，轮胎可以看成是一个领域对象的聚合，轿车是这个聚合的根，如果我们想访 问轮胎，必须通过轿车的导航来进行，为什么如此规定，因为轿车和轮胎之间存在一个不变量：一个轿车有四个轮胎，如果允许客户端直接访问轮胎，那么就很难保 证此逻辑不被破坏。

服务这个名词被用过很多次了，但是以前人们说的服务大多是从技术角度而言的，从分层来看属于应用层。一般是诸如注册成功发送一个邮件之类的东西，领 域驱动设计中的服务不是这个范畴的概念，它强调的是实体之间的相互关系，而不是纯粹意义上的技术手段。举一个例子来说：CMS系统里，如果一篇文章被加入 精华，则文章作者的经验值加一。此逻辑中涉及量个实体：文章实体和作者实体。经验值加一的逻辑不管是建立在文章实体里，还是作者实体里都显得冗余，所以有 必要在实体之上在抽象出一个服务层来处理。这里可能有人会问：这样的逻辑我们放到传统意义上的应用层不行么？那样做不能说不行，但是多数情况不好，因为此 逻辑属于领域逻辑，而不是应用逻辑，如果放在应用层，领域逻辑就外泄了，领域层也就成为了摆设，但是也有例外，有时候我们可能一时很难分辨一个逻辑是领域 逻辑还是应用逻辑，这个时候把此逻辑加入到应用层是没有问题的，如果以后发现其作为领域逻辑更合适的话再重构不迟。

写完了回头看看，感觉只能称之为涂鸦心得，领域驱动设计更多要靠自己的体会。