要领域模型干嘛？

写代码方便
与看代码方便

本身是矛盾的.....

但有些人非要把写代码不方便,
看着也不方便的东西当流行.......非常不适应.


好像领域就比非领域好似的.
不领域就该死一样

其实是一种习惯的问题，当你适应了充血的模型，让你回到贫血下的编程你会感到很不方便。反过来同理。

其实两者可以都解决问题。

写代码方便与看代码方便本身没有任何矛盾。

领域模型目前的意义仅仅在于分担一部分无状态的逻辑。

对于一个User来说，它的内部你可以封装一些你认为他可以具备的逻辑，但是这些逻辑都是无状态的，也就是与实例无关。比如说:

// 标志当前user不可用
public void disable() {
     this.disabled = true;
}

// 验证是否有效
public boolean authenticate(String password) {
     return this.password.equals(password);
}

我从来认为UserService这个东西是不可少的。只是说，如果把所有的逻辑全部放在UserService中，你的UserService会过于臃肿而不易于维护，把一些无状态的逻辑封装在User中，可以让UserService更加清晰，同时这些逻辑可能会在很多个其他的Service中共享。

至于说到持久化操作，无论是查询还是保存，我们都把相应的逻辑写在Service中吧，否则，User也会变得不可维护。事实上，所谓的把持久化操作，包括查询，修改，保存，都放在领域模型中，只不过是技术上的技巧，并没有在代码上给我们带来质的飞跃。

搞点复杂的逻辑，真正去写一个系统，试试看把所有的逻辑都放到领域模型中，或者把所有的逻辑全放在Service中，然后再比较一下，怎么写比较好，这样不就能得出结论了嘛。

对应一些复用度高的功能放在领域模型里面还是非常合适的，其它的一律放在service。还有涉及单个实体的操作放在模型里面也是比较好的。

所以不是很清楚了嘛，大家都不喜欢“麻烦”。所以，到底怎么实现，根据实际情况来呀，就好像 ronghao 说的那样。

脱离了实际环境而讨论，一点意义也没有。就好像之前大家比较到底 native thread 好还是 green thread 好一样。

你说的很有道理。做一件事情一定要有理由。难道领域模型就比非领域模型好嘛？希望有具体的论点说明，两种实现业务逻辑的方式的好处和坏处，以及使用场合，和为什么。如果只有一个观点和结论，无助于互相提高。

为什么模型简单，为什么可测试性强。具体怎么事先不谈，我会新开一个帖来讨论各种实现方式的问题。让我们先来讨论POJO充血能带来什么好处和坏处这个问题。

大家都不喜欢“麻烦”只是一个结论。我想知道的是，为什么麻烦，为什么没有好处，或者有哪些坏处。如果这些成本和收益的分析需要结合实际例子，那可以自己给一个例子来支持自己的观点嘛。我们当然知道没有golden hammer，没有适合所有问题的解决方案。但是每个方案都有适合自己的场合，都有好处和坏处。那为什么不来讨论一下呢，还是说这样的讨论本身就不可能有结果，没有意义。

理由是什么呢？怎么定义“复用程度”高？为什么在领域模型里只能放涉及单个实体的操作呢？

用mixin实现领域模型是最简洁的做法, 但是受到Java语言的限制，得用大量mark性质的interface和composite模式，反而会让整个结构变得复杂。
相比C#的namespace或ruby自定义dsl（acts_as_xxx），在java玩领域模型需要更多的功力，推荐一下Rickard Öberg的qi4j，它将composite oriented发挥到了极致：
http://www.qi4j.org/