领域模型的价值与困境

PS: 有个问题是充血或者贫血模型带来的。

存储过程是平台无关的，你爱用python，用perl，用C#，用java，全部是结果一致，这种需求往往出现在核心业务里，比如BOM系统。

消除DAO的结果 很有可能又出现Entity Bean,持久化由容器控制。

形而上的东西，讨论起来或许有意义，但是会有结果么？

对象持久技术使得Dao存在的意义已经不大，因为Dao的初衷之一就是数据库sql切换的屏蔽，Dao只是一种设计模式，它是充血模型的敌人，把Dao破掉领域模型就有了，其实领域模型就是Manager+Dao的混合体，但是无论是Manager还是Dao，他们的角色都是代理，也即是说，他们是数据的控制者和操作者，而且命名方式极其“粗暴”，何为Manager?何为Dao？这些术语都是编程领域的，而不是业务模型领域的，所以除了实现技术的转变以外，领域模型在java的实现还有术语和思路的转变。同意robbin的说法。

这张图其实革命还没革彻底
现实开发的过程中，实际碰到的情况往往是数据本身涵盖的内容大过了Conext
我定义Conext的时候我根本不知道这个Data有多大，有多少内容，还有其他多少Conext要去管理它
不是三个饲养员一起伺候一头象，这个场景还是太理想太一厢情愿了
而是三个瞎子，这个人摸个耳朵，那个人摸个尾巴，大象本身什么样子？你永远不可能知道

所以说面向对象的“封装数据”这个思想放到现实里是很可笑的，领域模型必须彻底放弃对具体数据的独占权才是出路
我倾向于把信息世界里最终进行管理维护的核心“数据”，与代码编写中用于码砖头的“变量”彻底分割开来
这话的“数据”和“关系”单独封装组织起来，而领域模型只允许对抽象的“数据”和“关系”进行操作
而具体“数据”怎样组织，我举个例子，一个供应商系统和一个客户系统，那么同时既是供应商又是客户的对象放在哪个系统里呢？我做领域模型的时候不应该管理这个问题，我只要处理好供应商系统的逻辑，客户系统的逻辑就好，最终定义是这样：

var 系统A=客户系统.new
var 系统B=供应商系统new
var 数据C=数据集合实例.new
系统A.注入（数据C，'客户数据')
系统B.注入（数据C，'供应商数据')
数据C.列出接口
//返回：作为客户系统，方法1方法2方法3
//     作为供应商系统，方法A方法B方法C


我对将来的发展的看法，就是面向集合/面向关系的对象系统，而面向对象的集合/面向对象的关系这一套应该消亡了
这个调调的脑筋我动了很多年了，JE高手多，看看谁能搞出来

现在越来觉得这些框架好像偏离了面向对象的思想，弄一大堆pojo类出来，这些pojo类和残疾人没什么区别，也怪不得叫贫血。
例如：一个person类，有名字属性，有手属性，有脚属性，却偏偏不能给他一些行为，你们说有手有脚的人，不给他干活，那和一个废人有什么区别。
偏偏要把这个人的行为要由别人去决定，例如Service层或者dao层等等，我要找张三去干个活，还得先找个中介，转来转去，真没意思。。

存属于发发牢骚。。。

DAO是从系统的角度来看问题，它面向系统，不包含领域逻辑是应该的。理想化的领域模型应该只描述领域模型之间的相互作用和相互作用的结果，结果可以是一个新的领域对象，或者原有领域对象发生了变化，这个领域对象变化通常是永久，映射到系统上就是要被存储，当需要参与下一个相互作用过程的时候被调出来。

每时每刻都有不同的领域模型被调出来发生相互作用。基于物理系统的有限性，领域模型会被做某种调适，这也是为什么领域模型经常被扭曲的原因，领域对象要穿梭与机器的不通物理系统之间（内存和硬盘，不同的主机之间），假如“保存”“传送”这些动作不存在了，现在有多少框架和模型要推翻？有时候，为了性能，领域模型需要见到这些不应该见到的东西。

JAVA最大的限制是没办法方便的mixin,没办法方便的粘贴“行为”和脱钩“行为”。而基于关系数据库的系统的最大限制是没办法随意变更你的领域模型。

领域模型是针对某个领域内数据和行为的封装。既然针对不同的Context。我们完全可以使用不同的领域对象
contextA.User
contextB.User
contextC.User

他们实际上对应数据库中的同一张表。
就把ContextA.B.C 当作3个完全独立的子系统。 只是需要共用数据表而已。

Wow总结的很好。却是是这样的。qi4j对于这两个问题的解决方法是用Composite Oriented Programming来实现mixin，不过我觉得那个实现很罗嗦，不大实用。对于后者的解决办法是压根不用关系数据库做主要的存储，只用来做异步地备份和reporting，主要的存储用neo4j之类的网络数据库。最大的好处正如你所言，没有固定的schema，也就意味着多个不同版本的对象可以同时存在，也意味着不用关闭服务器就可以升级版本。

对，确实是这么做的。有的时候对于同一个对象，我们会用不同的包装类来包装它，附着更多的行为。但是带来的问题是“对象的身份危机”，一个对象有多个身份。这样对于使用者就造成了混乱，上下文有多个对象其实代表了同一个东西不好懂，写起来也罗嗦。