要领域模型干嘛？

说说个人的理解吧。

领域模型，我觉得更大的用途是在分析阶段，而不是在实现阶段。而 ddd，更重要的是帮助你如何去理解业务，分析业务。

实现？对于应用软件来说，复杂度是有的，但是通常情况下并不那么复杂，复杂的是业务，所以，在分析阶段引入领域模型是非常有意义的。

至于楼主讨论的实现方式，我觉得没什么意义，这个冷饭炒得没前几次好。“到底用什么好”->是一个没有答案的问题，不同的场合，不同的规模，会有不同的实现方式。

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

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

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

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

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

我觉得根据业务需求吧

过于复杂的需求还是用贫血

一般需求用充血

说实话我是喜欢用充血，而这方面ROR里的model做的最好。

充血的model的确更有意义，并且更方便。

你说要领域模型干嘛？可以去比较一下国内的一些面向过程的PHP的CMS，看看如果没有领域模型，是什么样的情况。

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

我挖了这么大的一个坑，就是为了把qi4j引出来。唉，这下就没什么玩的了。

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

对于一个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中，然后再比较一下，怎么写比较好，这样不就能得出结论了嘛。

题外：Qi4j的logo我喜欢--- 不是咖啡是“拉面！”