要领域模型干嘛？

使用Spring和Hibernate其实也可以基本上消除DAO层，将事务控制这一部分提到Application Service这一层来进行控制，当然一些复杂的查询这些需要写在Repository中，Repository本就是与数据库这些infrastructure相交互的

这几天也是对领域模型迷惑了，在论坛上看了一些讨论，结合自己的认识说一下：
其实领域模型定义了一个起点，让你整理领域中的知识，进而模型，而随着对领域的认识加深，以前的领域模型肯定有不适合的，这就可能需要调整，也就可能是变化的需求，其实感觉需求没有变化，而是种种原因我们没有认识清晰，看看DDD那本书，上面更多都是在讲浮现更合适的领域模型。
另外充血也好，贫血也罢，都是根据实际情况，关键是要认清领域中的知识，就是有一样，使用贫血模型，可能导致事务脚本，这样在领域（知识）模型的进化的过程中可能就是有害的。对于贫血和充血，不要仅仅站在数据角度看，如果光看数据，我们也就是在折腾应用的状态。这也就是网友所说的还有流程，不仅如此，我认为还应该有规则。
再者就是对于领域模型的讨论，无一例外都要说到持久，因为这个似乎成了一个绕不过去的坎，我们想隔离实际的领域对象，但是最重要的基础设施的代码持久在干扰你，有框架的问题，也有概念的问题，这一点感觉在j2ee core pattern中倒是有点到。
最后就是重构，其实重构这个玩意，martin大叔开了头，但那本书重构的书名副标题就告诉了你重构的层次，是基于代码的，消除代码上的坏味道，后来有人写重构和模式，提出了更高层次的重构，想着模式的目标走，找到合适的模式来改善设计，再后来DDD中的算是把重构总结了一下，最高境界是向着模型走，浮现好的描述领域知识的模型，而且特意写了一章说突破，不过回过头来看看重构，我们确实这样走过来的，代码改善，引入模式，模式解耦，浮现模型。
我们坚持领域模型说白了就是三层架构和OO。

Repository 也是领域模型的一部分吧，如果使用spring/hibernate，最终的结果是否还是会造成领域模型会依赖这些对象的结果。要想完全消除，很难。如果不考虑spring，应该容易很多。

好长的贴.

对于流程类的逻辑,查一下,删一下,发条短信这样流程类的逻辑,我觉得写在service层挺好.

对于业务规则,可以尽可能的放在domain里. 

不知道大家看过jBPM的代码没有,个人认为,那个已经是很好的范例进行面向domain的代码了.不过,毕竟jBPM跟我们做的系统类型不一样,不过借鉴一下还是可以的.

望指正.

给领域对象分配职责，各领域对象各尽其责，各肆其职，易于复用、扩展，便于维护、理解。
掌握行业的领域模型，就可以靠咨询、做顾问为生，大可不必去做开发。

To robbin:
关于第1点，你真的说过，下文引自你的另一个贴子．
我个人很赞同lifethinker的说法，你确实在认定充血贫血时过分强调了持久化．
你还有一个观点就是：用了ROR就必然充血，用了Spring就很难充血，这些应该都是和你这个认识是直接相关的．

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
http://www.iteye.com/topic/17579

二、贫血模型

贫血模型请看
http://forum.iteye.com/viewtopic.php?t=11712
中列举的第二种模型，简单来说，就是domain ojbect包含了不依赖于持久化的领域逻辑，而那些依赖持久化的领域逻辑被分离到Service层。
Service(业务逻辑，事务封装) --> DAO ---> domain object

这种模型的优点：
1、各层单向依赖，结构清楚，易于实现和维护
2、设计简单易行，底层模型非常稳定
这种模型的缺点：
1、domain object的部分比较紧密依赖的持久化domain logic被分离到Service层，显得不够OO
2、Service层过于厚重

To robbin:
还是那个贴子里，你给出了贫血充血的认定标准．

---------------------------------------
贫血模型中我提出的按照是否依赖持久化进行划分，这种标准是非常确定的，