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

价值

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

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

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



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

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

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


    45 楼    redhat    2009-11-03              pufan 写道
在我看来，服务即契约，面向服务设计即面向契约设计，契约可大可小，大至异构系统间互通的设计，小至一个方法的定义，都应该以契约驱动，将变化封装，何有粗细粒度之分。

这里讨论的粗细粒度是指所提供的接口能够解决粗粒度的问题，我不想让你的暴露接口解决问题时，比如发送一份邮件，别人要调用你的暴露的其他接口例如： 判断这个邮件有没有发件人，有没有收件人，然后调用你的send接口发邮件。而应该暴露一个借口sendMail即可。不懂得粒度的粗细 ，如何设计程序？ 举个很简单的j2ee应用的例子：难道你没有使用过任何session fasade模式？

pufan 写道
你举的是产品的面向第三方接口的例子，先不说目前产品和项目的应用谁多谁少，就拿上述产品例子中访问数据库的代码量来说，需要DAO设计的代码有其他代码20%吗？
按28原则视之，以20%的可能性要求剩下80%也要如此设计，这不是大忽悠是什么？

首先，dao层的出现并不只是为了切换不同的数据库，如果这样有hibernate就够你使用了，dao层并未由于hibernate兴起而不复存在，因为他们是解决不同的问题产生的！
第二，这也不代表你完全有权利选择一种orm工具，其他orm工具你有权利不选（特别是“政治”问题） 。
第三，dao的提炼，可以让domain和service更关注自己的业务，每一个对象功能最好专一，完成自己本分的事情，这是面向对象语言设计的基本原则！
第四，你的20-80原则只可能说明你开发设计的软件具有此特征，不需要dao层可能适合你的项目，不一定适合其他所有项目！特别是复杂的，和大型电子商务项目！