要领域模型干嘛？

从一个题外话：

扩展方法，动态+ C# 5.0中的“compiler as service”-- 这样很容易实现ruby的monkey_patch，这些语言的基础特性集合在一起，是不是完成“动态充血模型”了？

写结构化的代码一定会比面向oo的代码快吗？
OO太久了过程化代码写起来也比较慢了。

楼主你非要让大家举出例子，那告诉你一个简单的方法：走访20个软件公司，了解他们成功的项目，再看看是否哪个用了领域模型，哪个没用，以及使用的理由。

事实就是：领域模型的使用与否，是要看实际情况，这包括业务，人员，开发方式，等等。

这个话题和以下话题类似：
1、敏捷软件开发好不好？
2、面向对象和面向过程哪个好？

所以，楼主如果你真要挖一个大坑，可以限制点条件，比如对于某某应用，某某业务，某些场合，然后大家再讨论是不是应该使用领域模型。

谈点感想：
也读过POJO in action, DDD, Flower的企业应用架构模式。

Flower的建议是：
  1）小规模系统用事务脚本
  2）中型的可以考虑表模块
  3）复杂的一定要用领域模型

个人感觉，DDD强调对问题领域建立模型，通过不断对问题领域认识的加深，进行模型的深层次重构，使之不断趋向于真正的领域实质，这个过程中领域是一等公民，而不是技术。

好的领域模型，应该是比较稳定的，但同时也是能更好的适应变化的。
1.事务脚本，实现起来很直接，很快捷，但重用性不好。当业务变得越复杂，代码重复等问题就会越严重，同时复杂的业务职责不能很好的被分担，导致过程和方法过于复杂、庞大或混乱。
2.领域模型，理想情况下能很好的通过实体、值对象、服务、工厂、仓库等建模领域，并合理划分职责，新职责的添加也更加容易，以支持业务变化。用领域模型，想起一句老话：“万变不离其中”，好的领域模型应该更加接近于这个“中”。
3.表模块，这种我没有用过。

DDD我觉得是分析和设计的综合，是通过对象思想建模问题域，并本着面向对象的原则，通过不过的学习、认识、重构，深化对问题本质的认识，并提供面向对象的解决方案，在这个解决方案中以对象化的领域组合在较深层面反应领域，支持表层领域问题（需求）。

前边有人是“职责”划分很重要，很认同。《对象设计——角色、职责和协作》是本好书，不过不太好读。

个人觉得，做领域驱动要求很高，也不容易做好。
但是，如果真的做好了，那的确是很理想的选择。


普通的项目贫血的POJO应该就可以了，要求不好，实现起来比较统一，也很方便。

“业务逻辑”会给大家造成误导，什么样的代码才是业务逻辑呢？ 只有改变来源于自身的代码才能写在模型内部，如果改变来自于外部你的模型就是不成功的。支持业务模型，但不要乱用。
遵循设计原则下产生的领域对象或者设计才是值得大家去支持的。而不是为了领域模型而去领域模型。

问题是我们知道要看实际情况。我没有绝对的说，要打倒一个，树立另外一个。我是尝试让大家去思考为什么？然后，当你作为一个Tech Lead，来开一个新项目的时候，你知道你的项目是什么类型的项目，人员构成是什么样的情况，应该用哪种方式来组织你的代码。同时，作为一个Community的一员，也可以反思一下，Spring+Hibernate是不是又变成了当年的EJB，人们又开始stop thinking了？
即便答案是It depends，探讨It depends on what也是有意义的。

谁来给领域模型下个定义阿,据一个例子什么样的代码叫做领域模型.看你们聊了这么久,也到其他地方搜索了一下,都没有找到什么是领域模型!

思考的结果是什么呢？我觉得和领域模型没关系了，似乎是如何做好一个项目。

你也说了，你想引出 qi4j，我想这是一种实现方式吧？和你的题目也对不上呀！如果你想表达这样的结果，这个帖子的题目应该是：“怎么更好的使用java来实现领域模型”--- 不过这个冷饭你以前似乎炒过，俺看过 :-)

如果这个说法是正确的话,那么领域模型就是业务逻辑的一个实现, 难道还需要讨论要不要领域模型吗?不要领域模型的话, 业务实现都没有了,还谈得上什么软件阿.

在韩国出差的时候，见过一个项目，也很大的一个项目，大概100人做了两三年。
在他们的框架中主要的工作在两块：
  前端用XForms
  后端的逻辑基本上被集中在sql上，也就是他们很多逻辑是在数据库上完成的
     （action、service、dao除了有针对map到xml必要的转换很少有别的东西）
  前后台用xml交互

感觉很极端，但参与了两个月，除了些sql不爽，其他方便都不错。
尤其是XForms，感觉比AJAX优雅干净的多。