什么什么乱七八糟的，vo是反模式，真搞笑，中毒太深了。什么是域模型，这些是别人提出来的，明白吗？不是死的东西，我干吗要按他的理解去理解呢，我更多是从成功的案例中来，当然我不是不信书，但我只信那些在实践中是被证明过的书。我个人老觉的我们需要创新，创新需要借鉴，但借鉴的应该是理念而不是实体的东西，理念才是引导着我们有新的东西出来，说我不明白什么是域模型，难道知道了人家怎么说域模型，然后你去依着说你知道吗，你知道什么是域模型，真搞笑，知道了域模型又这么样，那不深究它要反映的解决问题的方法，为什么要这样，那就等于知道它的形，但不走到它的神。难道用Dao+Vo来不就一样解决人家说的域模型解决的问题吗？并且这样的化对象更细分，容易封装和组合，明白了吗？域模型想解决什么问题，不就是对象到关系型数据库的映射吗? 还有什么新意，告诉我，是从业务建模中来的，我先告诉你，为什么会从业务建模来呢，因为业务处理的时候需要参就就算的数据集合，需要它们，那这些数据是在哪里，是在数据库里的，但我业务建模的时候只是OOA出来，出来的域模型是对象，他们的关系要映射到关系型数据库是又一些问题的，那么就应该分开数据就数据vo,操作是操作 Dao。这样的话就容易使用composite模式来复合或者分解来解决域模型和关系实体之间的矛盾。唉，我的天啊，就谈到这里。如果又什么觉得可以吸取的就表声谢谢，没有就算了，我不喜欢玩概念。
Domain Object提供了足够的信息,为什么不用它呢?
是的,在一些框架里面,你不得不不用其他的对象,例如strcut,你也许需要转换成formbean来使用.但是你如果使用webwork,那么很庆幸,你可以轻松解决这个问题,实现ModelDriven就可以让你的表现层轻松访问你的domain object.用dto来作为service的参数,将使你的domain object的威力有所减弱,service的接口膨胀,让client再次感觉到结构化编程的痛苦.嗯?我需要调用service,传入一个部门的dto或者Id来得到部门里面的人员码?不,部门(domain object)本来就应该知道它有哪些人.
中毒?哦,也许是的,中了OO病毒,哈..
域模型不是我想出来的,是别人提出来的,这个你算是说对了 ,估计提出这个的人也中了OO病毒,也许比我严重的多 :).
我提出这些,只是觉得这中方式可以更好的进行OOD,这个不是概念,是开发中很实用的设计方式.
知道域模型不能怎么样,至少不能成为比尔,哈..其实不用它也可以解决问题,有朋友和我说,我在jsp中写全部的代码,比你的方式快,而且方便.呵呵..我对他说,你算是说对了,不过你要加上一个环境描述,那就是你做的是一个hello world...任何设计和实现方式都有它的理由和使用环境(Context),我一再强调这个.
使用何种方式，都是由利益决定，也就是这种方式能你给带来多大的好处来觉得。
使用那种方式多没有对不对的问题，只有好不好和合不合适的问题。
大家在这里探讨问题目的是为了相互借鉴相互提要，找到更合适的方式。
DAO+VO方式也许是可行的一种方式，但不一定是一种好的方式。如果认为这种方式好的，可以说说它好在哪里，
能增强系统的灵活性和扩展度吗？
能提高开发的效率吗？
有更好的可重用性吗？
能有效的提高系统的性能吗？
等等，
如果能也请说说问什么。
还有如果是把要数据和操作完全分开，那是不是等于说ADT(抽象数据类型)毫无价值了呢？由此推论是不是可以说明基于ADT的面向对象理论是没有任何价值的呢？
TO 浆糊，表现层直接访Domain object，会不会造成domain object和表现层紧耦合呢？例如为在表现层显示所有部门的所有用户，在完全不要服务层的情况下得到所有部门的所有用户这个方法是放到部门类里还是用户类里呢？
域模型过分的复杂，我认为也不是个好注意！
但我不是说域模型不好！！
TO:mote_li
我觉得显示层使用doamin 对象可以更方便的达到需求,不需要做domain->dto的转换,其实说到耦合,我认为dto不能和好的解决显示层的耦合,如果domain变化了,dto大多数情况下还是需要变化.
服务层是需要的,但是它的职责只是facade,不是business logic.所有部门的下的用户,我一般的处理方式是使用repository模式来解决,因为它是对entity的一个查询,可以不纳入domain object的方法中.
TO:zhuam
domain object是业务概念的一种表现,只会关注属于它自己的属性和方法,所以说只有符合或者不符合业务模型的domain object,不会说是过渡肥大或者瘦小.让doamin object尽量真实的反映实际的业务对象是关键.
建立域模型也只是你看问题的视角，就是这个视角每个人有不同的看法，且有时侯你必须就某些问题做出妥协！
某些问题需要妥协是正常的,设计本来就是一种权衡.但是权衡不等于放弃
USER可以说是你对领域的一个认知或者说是一种概念.在你进行了分析之后将这种概念转化为了一个可以抽象的领域的模型,再进一步地分析和设计(添加属性,关联,分配职责)才得到你说USER类,我认为这是由真实世界转化到软件世界的一个过程.他是一个软件对象!不能和领域模型混为一谈!
还有楼上激烈讨论的只能说是软件架构和OO的设计,其实和领域模型的建模无很实际的牵连.只能说领域模型"暗示"了软件模型的产生.
还有道兄说的changePwd方法的位置.我认为这是一种分配职责的过程.根据Larman的研究，这种分配职责应该是按照“信息专家”的模式来分配的。即谁拥有完成该职责的信息，就将该职责分配给他。那么user中拥有这个方法是非常对的，而你所说的UserManger更应该是委派的角色。
nekesai:我在说一下，域模型就是一个数据载体
这种说法我亦不敢苟同。什么是域模型？难道你的领域模型只有表示状态的属性，而没有动态的行为？这叫什么领域模型呢,详细客户都不能答应你。当然，有时候从设计或者开发角度考虑，将领域模型简化成你所说的数据模型，这种情况是存在的。但是这种情况下，这个模型已经不是领域模型了，已经编程了一个为了持久使用的领域实体模型（PO），他不再是POJO。
nekesai:域模型想解决什么问题，不就是对象到关系型数据库的映射吗? 还有什么新意，告诉我
^_^，不好，有看到了一个我不能接受的说法。域模型是用户业务领域的反映，在考虑域模型的时候，我想大家并没有考虑如何进行持久。而当我们进行设计的时候考虑的是持久层的解决方案，才引出了o/r mapping。你所理解的域模型就如同我理解的PO，如果你硬是要把PO说成是域模型，那么^_^后果就不要我说啦。
所以感觉你的理解是有问题的。
域模型就是一个通过关联和继承层次而互相连接的对象的层次结构。域模型通常采用具有状态和行为的业务对象和它们之间细粒度的交互来实现,换句话说，域模型就是概念模型的面向对象的实现。所以用实体bean作为域模型的实现是不够的，也就是实体bean是不适合做域模型的实现的。
changepassword当然应该是user的方法啦
各位大侠能否给一份
<Patterns of Enterprise Application Architecture>
和<domain driver design>
感激不尽!
jehad_shi@163.com