这样说来只是不同人观察角度不同而已
[该贴被vcshcn于2009-02-24 16:49修改过]
能否从“满足不断变化的需求”方面进行对比，看哪个更易于维护。
例如订单中途撤销类似新需求。
2009年02月09日 13:36 "freebox"的内容
我在另一篇帖子里也发表了一下我的看法，我认为可以把这看成被动调用，像监听器一样。每当我要被保存的时候，我就通知一下管理者，叫它反过来保存我。由于现在我不用特别去理解管理者，它对我的应用来说是存在但不被重视的，于是就把它放进Model背后，而这时的Model类充当领域实体和Dao的结合，因为我从不关心Dao，而它在背后实现，于是在视觉代码上体现出来的就只有领域实体的特性。
而Java在这方面做得和ror等就不一样，它没办法这么做，要做的话，在视觉上就有显式的dao，于是一旦看到dao，我就知道原来它在那里。当然也可能会利用特别的编译器在编译期生成dao，从而在视觉代码上看不到dao，但实际在编译后还是有dao，但那都不需要人为管理了。
[该贴被freebox于2009-02-09 13:41修改过]
而Java在这方面做得和ror等就不一样，它没办法这么做，要做的话，在视觉上就有显式的dao，于是一旦看到dao，我就知道原来它在那里。当然也可能会利用特别的编译器在编译期生成dao，从而在视觉代码上看不到dao，但实际在编译后还是有dao，但那都不需要人为管理了。
[该贴被freebox于2009-02-09 13:41修改过]
赞同你这种说法，领域实体无法自我创建，所以创建方法不能是实例方法，只能是类方法。当需要创建领域实体时，由领域实体类向领域场景发出消息事件，由领域场景触发相应的适配监听器调用领域服务完成持久化操作。在此还涉及到了实体UID的生成问题，实体存活在领域场景中，其UID不是在持久化场景中生成，应当由领域场景给予，显得更合理。
比如注册业务：
User要做的就是填好自身资料，提交注册请求，转化成代码就是给自己的属性赋好值，然后触发“注册”事件。
系统要做的是对User的注册事件提供服务，所以Application的某个Service提供了“注册”的服务方法，来处理User的这个事件。这个Service如果认为需要将User的信息持久化，以免丢失，就调用持久层进行辅助操作。
UI层就直接调用User Domain里面触发注册事件的方法。
这样Domain不是贫血的，各层又各施其责了。
以上是我的一点想法，如有误，请各位大侠不吝斧正。
最简单的方式，static 方法。