失血模型的请教

最近看domain model，好像大家都很摈弃失血模型，认为domain object中不能只有getter/setter代码，而应该加入不依赖於持久化的逻辑方法
为什么呢？
谢谢

那是人云亦云，是MF那套思路，目前实际就是这么做的，而且从四色图一直分析下来到实现，这样做起来好处很大，将领域模型组件和业务组件分离，因为业务组件包括逻辑方法还是需要计算机领域概念支持，如事务、缓存。

模型领域和计算机软件领域有些mismatch，这是现实，而且将来也不可能完全配对，如果为了建模概念完整，强迫软件领域做些不现实的让步，这种方式我是反对的，还是那句话：本来两者就不是同样东西，就象要求EJB模型完全让步于普通JavaBeans模型:POJO，EJB本身就是一个分布式组件，和POJO本质就不一样；还有O/R mapping，让代表数学意义的关系数据库让步于对象，也并不能解决所有问题，所以我们有时还是使用SQL。

什么事情都不能过，分离复用抽象不只是依靠面向对象oo，也就是说不能唯OO。看看SOA吧，多了解些更广泛的概念，这样自己才有把握。


其实就我个人的感觉和实际
这样的失血觉得很自然
而且，一般来说，getter/setter都可以直接生成
具体的开发过程中蛮容易接受的

>失血觉得很自然
同感，因为这种感受是从软件程序员角度出发。
但是对于一个不懂软件的建模专家来说，可能就不自然了，觉得怪异了。

汗！
不懂软件的建模专家

>不懂软件的建模专家
也就是系统分析师，可以不懂软件，所以一般假设他们不懂，实际也不需要他们懂。现在软件发展就是想作成直接听命于他们的软件，如DSL/DSM。

UML中至今没有将JavaBeans的Property(set/get)作为其核心标准，这就反映了技术和建模的不匹配。

阻抗到处存在，意见总是因为不同立场引发的。

另外：有人指责这样的模型不是一个完整对象，其实这是他对象概念的空白，这是GoF设计模式的桥模式实现，编程时分离，运行时组合，如果这个模型对象不是对象，那么桥模式就不是OO对象的设计模式？

所谓的“失血”模型，本人一直在用，没觉着在实际应用中有何不妥。
不知MF在国内很多fans为何非把它灭了不可。