DDD让我苦恼

关于领域模型的说法太多，各家都有各家的说法
jdon上说
http://www.jdon.com/mda/ddd.html
DDD关注的是业务层
业务层分为应用服务层和领域层
领域模型由service+实体＋值对象　共同完成
service是应用服务层
实体和值对象属于领域层
在我们的论坛上有出现很多人说
要业务和实体是不可分割的．这样才能体现ＯＯ，就是和上面说的相反咯．
总之我觉得在实现业务目标的前提下软件最终的目标就是要实现复用，易维护，易扩展
至于实现这样的目标我想大家都有满意自己设计的立场，所以就会有争论．
不过我还是想透视一下各位高手们的说法，并给出理由．
我个人觉得如果可以在这些选择之间找到一个平衡点并合理的构件我们的项目才是我们的目标
不过技术终归是技术，需要证实
希望大家支持，谢谢．

领域模型,领域对象之类的术语太虚了,
说句老实话,没有个三五个以上大型项目设计经验的人,
谈论这些是没什么意义的.

而当你真正拥有足够的项目经验与教训(!)后,
就会明白,简单才是一切,敏捷才是王道.

我想做技术的人应该在这个问题上权衡一下吧，也确实没错，没有办法
很多人都向敏捷屈服．但不表示所有的人都向它屈服，
考虑不完整的敏捷会牺牲更多的时间．
我想得到合理的技术上的实现，关于领域模型着很重要，我想得到好的意见．

> 向敏捷屈服．但不表示所有的人都向它屈服

屈服??? 
我喜欢用我才敏捷,我在实践中体会到了它的巨大好处我才用,
推广敏捷的人,大多是相对无私的一线资深开发人员,
相反推广DDD的人,则多是以推销他们公司产品为目标.

算了,说多了又成了意义之争,就没意思了.

敏捷不是不好．如果不好就不会有那么做了．
我自己也体验过．
我只是就领域模型这个问题想得到证实一下
可行也成功的做法，没有要去说敏捷不好．

感觉业务层还是要的，把涉及一个完整动作（事务）的代码封装在业务层，把涉及实体对象自身状态改变的动作封装在实体自己的类里边。不知理解是否正确，将业务代码放在实体类的确是符合OO，如果这样是不是要将事务赋予实体类的方法，但AOP方式来给实体类加载事务是不是开销大了点。还是可以通过转移事务的边界来解决？（例如将事务放在每个Controller？）

敏捷和DDD有冲突么？奇怪 不知道你们在说什么 好好看看书先吧

我也不知道那兄弟为什么总要说敏捷．
我想要谈的是ＤＤＤ的了．
觉得说法有很多，希望大家把实践中的经验拿出来分享～
这样国人的水平才会提高嘛～

领域模型应该是分析层面的东西。Service, 实体类，值对象这些都属于实现层面了。好像扯不到一块去啊。

班长现身，这帖貌似不该在这个版里。