领域模型的价值与困境
 

2009-04-29 作者：taowen 来源：taowen的blog
 

很久以前大家就关于这个方面有很多讨论了。前两天我又挖了一个坑来集思广益，非常感谢没有把我的帖子投为新手帖的同志。我不是在装傻，只是想让大家跳出自己的立场，从根本的价值出发来考虑问题。之前有很多讨论，都是在讨论我又发明了一种新方法可以让领域模型充血啦，等等之类的。当提出一个解决方案的时候，一定要有明确的问题。那么领域模型的价值是什么？为什么没有被广泛应用，其困境在哪里？

价值

数据，一定是数据。做企业系统，最核心的东西一定是数据。关于数据，人们有许多需求，但是最根本的一点就是，数据要是对的。在关系数据库的上下文下，为了保证数据是对的，我们有外键，我们有COLUMN的数据类型，我们有主键，我们有constraint，我们有很多很多。但是很多时候还不够，一堆数据在业务上是不是合法的，超过了上述的检查方法的能力范畴。这个时候，以DBA为中心的思考就会导致：我作为DBA，管理这些数据，如果数据出了问题，那就是我的责任了。所以我必须要阻止愚蠢的事情，而我显然是最知道什么是正确数据的人，所以你们（程序员）要访问我的数据，就必须通过我的存储过程。

这种方式显然遇到了问题。问题是很多方面的，有人员素质问题，有工具支持问题。更重要的是，虽然存储过程起到了防火墙的作用，阻挡了外界可能的对数据一致性的破坏，但是其内部却是脆弱的。数据对于包裹它的存储过程都是开放的，写存储过程A的人，可能对数据的假设与写存储过程B的人对数据假设是不一致的。两个人必然只有一个是正确的，但是从数据出发找到修改它的地方并不容易，从而给数据的质量埋下了隐患。

存储过程的问题，就是面向过程的代表。面向对象的主要特征，封装就是为了解决这个问题发明的。把数据放置于对象内部，要修改对象所封装的数据，就必须通过对象所提供的外在行为。有如下图所示。


回到数据的正确性这个问题。程序员不同于DBA，给出的解决方案是领域模型。其实领域模型，只是面向对象的另外一个名字而已。通过把数据封装在领域模型的内部，我们就可以限制模型的使用者对数据的修改，什么值是对的，什么样的值是不对的。具体列出来有：

构造函数

可以确保在创建的时候已经有了所有的必填项

Java代码 复制代码
  1. public class Person {   
  2.   public Person(String firstName, String lastName) {   
  3.   ...   
  4.   }   
  5. ..   
  6. }  

无Set方法

不能任意的改变值，必须通过特定的合法性检验

Java代码 复制代码
  1. public class Publication {   
  2.   private State currentState;   
  3.   public State publish(Channel to) {   
  4.   ...   
  5.   }   
  6. ...   
  7. }  

关联

可以保证外键，以及强制约束两个表之间数据的关系

Java代码 复制代码
  1. public class Cargo {   
  2.   public void attachItinerary(final Itinerary itinerary) {   
  3.     // Decouple the old itinerary from this cargo   
  4.     itinerary().setCargo(null);   
  5.     // Couple this cargo and the new itinerary   
  6.     this.itinerary = itinerary;   
  7.     this.itinerary.setCargo(this);   
  8.   }   
  9. ...   
  10. }  

一致性

冗余字段的同步更新得到强制

Java代码 复制代码
  1. public class ShoppingChart {   
  2.   private List<OrderItem> items;   
  3.   private int sum; //冗余字段   
  4.   public void dropIntoChart(OrderItem newItem) {   
  5.     sum += newItem.sum();   
  6.     items.add(newItem);   
  7.   }   
  8.   ...   
  9. }  

当然，面向对象不光是封装一个特性，它还有继承和多态。所以作为面向对象的另外一个名字，它自然也有继承和多态这个好处。具体到程序里就是

枚举值

不要通过对枚举值的判断来决定程序的路径

Java代码 复制代码
  1. // 过去   
  2. public void publish(ChannelType channelType, Publication publication) {   
  3.   if (channelType.equals(ChannelType.RETUERS)) {   
  4.     ...   
  5.   } else if (channelType.equals(ChannelType.BLOOMBERG)) {   
  6.     ...   
  7.   } ...   
  8. }   
  9. //现在   
  10. public interface Channel {   
  11.   void publish(Publication publication);   
  12.   ...   
  13. }   
  14. public class RetuersChannel implements Channel {   
  15.   ...   
  16. }   
  17. public class BloombergChannel implements Channel {   
  18.   ...   
  19. }  

数据的含义

另外一个好处是，对数据的访问被集中起来了。所以，从数据出发，很容易发现计算出值并修改它的地方。这就方便了我们去理解数据的含义。数据本身是没有任何意义的，数据只有被使用才有意义。只有理解了数据的上下文的含义，才能编写更多的行为去操作数据。在写新的行为的时候，我们必然要参考过去的行为是怎么理解数据的含义的。这个查找的过程越容易，越有助于我们写出正确的逻辑，也越有助于我们发现过去已经写过一样的行为了，那我就不用写了，也就是所谓的复用。

所以，理论上来说，面向对象或者说领域模型是非常适合我们的日常的企业信息系统开发工作的。但是，实践中，却遇到了很多问题。

困境

框架的约束

如Robin所言

robin 写道
如果你用的是Spring，没啥说的，必须贫血，你想充血也充不起来；
如果你用的是RoR，也没啥说的，直接充血，你想贫血也未必贫得下来；

这就是一个基本事实。Spring作者也坦言（Rod Johnson, JAOO, 2006)，Spring的编程模型基本上是EJB的延续。从架构和分层的角度，它们是一脉相承的。这种分层的架构决定了，行为在Service里，数据在Entity里。这种做法成为“最佳实现”，不是偶然的，是框架设计给你的必然结果。矛盾的集中体现在于Entity无法被注入（当然你可以注入，但是这是不推荐的做法）。Spring后来尝试修复这个问题，引入了AspectJ来做Entity的注入。不过仍然不是主流，因为框架的阻碍只是一个小问题，更大的问题在于这个Java的OOP实现本身就有问题。

语言的约束

在很多的讨论中，反对“充血”领域模型的同志都提到。把逻辑集中到领域模型中，会造成类的膨胀。在我个人的实践中，近千行的Entity类定义也是有的。而且这些行为往往不稳定，往往流程高度相关，复用程度并不是想象的那么高。
原因是因为，数据并没有所谓的内在行为。你不用它，它就没有行为。所以数据有什么行为，其实是使用者赋予的。而同样的数据往往会在不同的场合（context）下被使用。正如这位同志所言：

coolnight 写道
我们的系统有很多模块组成， 各模块基本上通过数据库来共享信息。
主要的模块大致有： 核心系统（非web）， 网站、 bbs、 网站后台，核心系统后台，BI， 推广员等等
原来的打算是写个rich domain model供各模块来使用，以便代码重用减轻个模块开发的工作量
一个简单的例子， User 原有 changePassword, getFriends, addFriend ... 等等方法撇开配置以及获取User对象的复杂性不谈， 实际开发中发现， 这些东西重用的地方太少了，对网站来说很好的rich domain model， 在网站后台里面就麻烦，很多方法在那里根本就是对后台开发人员的干扰，而很多方法对核心系统、BI等等根本就毫无用处。

所以上面所画的图就得改一下了：

同样，很多同志也发现了这个问题，并给出了解决方案

Quake Wang 写道

用mixin实现领域模型是最简洁的做法, 但是受到Java语言的限制，得用大量mark性质的interface和composite模式，反而会让整个结构变得复杂。

相比C#的namespace或ruby自定义dsl（acts_as_xxx），在java玩领域模型需要更多的功力，推荐一下Rickard Öberg的qi4j，它将composite oriented发挥到了极致：
http://www.qi4j.org/

ray_linn 写道

我建议用C#的扩展方法，或者Java用mimix（不知道打错没有），Domain还是POJO，方法在适当的时候“黏合”（C#通过 namespace引用）到POJO上，让POJO “充血”，而在充当VO，DTO的时候，POJO又可以“放血”回到“贫血的”状态上。

这个问题基本上是暴露了Java的OOP实现的缺陷。C#的Partial Class, Extension Method和Ruby的Mixin就是对这种“一个class定义一切”的做法的改进，允许行为被分片定义，而不是集中定义在一个文件中。

现状

很多同学都谈到现状不是完全的没有领域模型，而是所谓的贫血的领域模型。之所以会这样，就是前面所说的困境。正如很多朋友所说的，这未必是一件坏事，比如可以避免核心的domain过度膨胀。不过也未必是一件好事，理由我能想到这么几点：

越俎代庖

这是我们的DAO经常干的事情。比如我们有两个domain，Publication（一份文档）和Distribution（一次分发）。它们两者之间是聚合关系，也就是distribution必然属于一份publication。如果是重写的领域模型，我们可以通过publication来控制对distribution数据的添加。比如

Java代码 复制代码
  1. public void distribute() {   
  2.   if （isDeleted()) {   
  3.      throw new InvalidDistributionException();   
  4.   }   
  5.   distributions.add(new Distribution(this));   
  6.   lastDistributionDate = new Date();   
  7. }  

但是一旦有了DistributionDao，就不一样了。

Java代码 复制代码
  1. distributionDao.save(new Distribution(somePublication));  

哈哈，啥控制都管不了我了吧。很多时候Dao就是这么无法无天的。如果说domain model是数据的防火墙，那么dao就是顶级黑客。由于Entity不能注入等实现和宗教信仰上的限制，往往导致了service对DAO的滥用，就会造成上面这样的by-pass domain model的情况。

舍近求远

明明我有一个contact

Java代码 复制代码
  1. public class Contact {   
  2.   private List<ContactNote> contactNotes;   
  3. ...   
  4. }  

但是我不能直接去取我的contactNotes（性能啊性能，hibernate会load all啊）。所以我得写个查询

Java代码 复制代码
  1. from ContactNote where contacted = thisContact and ...  
  2. from ContactNote where contacted = thisContact and ...

我有一个contact就应该能够让我
　 Java代码 复制代码

  1. contact.allMeeetingContactNotes();  
  2. contact.allMeeetingContactNotes();

但是不行，你得

Java代码 复制代码
  1. contactNoteDao.findMeetingContactNoteByContact(thisContact);  
  2. contactNoteDao.findMeetingContactNoteByContact(thisContact);

舍近求远也

职责混杂

根据我理解的Service层的现状是：有一部分是作为domain model对外的接口，提供了事务安全等服务，真正是一个“service”对web层提供服务；有的呢，则是当作一些可重用的行为被注入到其他的service之中；而有的呢，则纯粹是一些utils。当然，不过可能是我用的不对吧，或者理解有误。

距离啊距离

数据和行为距离很远。造成了不容易理解数据含义，因为你光看entity压根不知道它会被怎么用。漏掉一些servie中细微的用法，就可能会造成很大的bug。

同时这也更加让可重用的逻辑更难被发现，从一定程度上鼓励了大家各自发明，一份逻辑写n遍，还n遍都不一样。。。

当然啦，这个问题没有想象的那么大，毕竟贫血的领域模型，还是鼓励大家把“只和这个对象，不和外部接口有关的”的逻辑放到对象本身的。问题的大小，取决于团队的稳定性，素质和职业操守。

术语

如nihongye同学所说，xxxService不是domain language。当然啦，讨论这种问题最终是仁者见仁智者见智的。

解困

你真的要解困吗？其实你未必被困住了。你可能根本不需要领域模型，特别是在Java/Spring这种实现下，难以实现。正如很多同志所言，我用贫血模型用得很好。那就行，自己好，就是真的好。但是有朝一日，觉得贫血模型不再适合你了，不妨去了解了解qi4j（如果你不想换语言），或者投入rails的怀抱吧。


火龙果软件/UML软件工程组织致力于提高您的软件工程实践能力，我们不断地吸取业界的宝贵经验，向您提供经过数百家企业验证的有效的工程技术实践经验，同时关注最新的理论进展，帮助您“领跑您所在行业的软件世界”。
资源网站: UML软件工程组织