领域模型的价值与困境
很久以前大家就关于这个方面有很多讨论了。前两天我又挖了一个坑来集思广益，非常感谢没有把我的帖子投为新手帖的同志。我不是在装傻，只是想让大家跳出自己的立场，从根本的价值出发来考虑问题。之前有很多讨论，都是在讨论我又发明了一种新方法可以让领域模型充血啦，等等之类的。当提出一个解决方案的时候，一定要有明确的问题。那么领域模型的价值是什么？为什么没有被广泛应用，其困境在哪里？
价值
数据，一定是数据。做企业系统，最核心的东西一定是数据。关于数据，人们有许多需求，但是最根本的一点就是，数据要是对的。在关系数据库的上下文下，为了保证数据是对的，我们有外键，我们有COLUMN的数据类型，我们有主键，我们有constraint，我们有很多很多。但是很多时候还不够，一堆数据在业务上是不是合法的，超过了上述的检查方法的能力范畴。这个时候，以DBA为中心的思考就会导致：我作为DBA，管理这些数据，如果数据出了问题，那就是我的责任了。所以我必须要阻止愚蠢的事情，而我显然是最知道什么是正确数据的人，所以你们（程序员）要访问我的数据，就必须通过我的存储过程。
这种方式显然遇到了问题。问题是很多方面的，有人员素质问题，有工具支持问题。更重要的是，虽然存储过程起到了防火墙的作用，阻挡了外界可能的对数据一致性的破坏，但是其内部却是脆弱的。数据对于包裹它的存储过程都是开放的，写存储过程A的人，可能对数据的假设与写存储过程B的人对数据假设是不一致的。两个人必然只有一个是正确的，但是从数据出发找到修改它的地方并不容易，从而给数据的质量埋下了隐患。
存储过程的问题，就是面向过程的代表。面向对象的主要特征，封装就是为了解决这个问题发明的。把数据放置于对象内部，要修改对象所封装的数据，就必须通过对象所提供的外在行为。有如下图所示。
回到数据的正确性这个问题。程序员不同于DBA，给出的解决方案是领域模型。其实领域模型，只是面向对象的另外一个名字而已。通过把数据封装在领域模型的内部，我们就可以限制模型的使用者对数据的修改，什么值是对的，什么样的值是不对的。具体列出来有：
构造函数
可以确保在创建的时候已经有了所有的必填项
