我想在实际系统中，crud并不是crud，而是映射到具体的业务动作上，所以应该在service之类的对象里
但在很多很优秀的开源软件里，确实crud是放到了domain中，我理解他把domain视为service，不知道这样理解对不对
这样说来只是不同人观察角度不同而已
[该贴被vcshcn于2009-02-24 16:49修改过]
各有所好吧.如果你的model类有很多,且大多业务都是crud,而你又不想让service层太臃肿了,那就到model中吧,虽然这样看上去怪怪的.但是有一点请记住别让domain层依赖于任何工具,比如spring.
能详细说下DDD的概念吗？
我觉得，如果把crud放入到domain中，那么crud方法应该是private的，不会是public，这样在domain的业务方法内部自行调用crud，达到隐藏持久化的目的，可能这样更oo一些
不论放在哪边，主要看我们是为了达到什么效果。
能否从“满足不断变化的需求”方面进行对比，看哪个更易于维护。
例如订单中途撤销类似新需求。
学习了。
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不是在持久化场景中生成，应当由领域场景给予，显得更合理。
楼上说得很好，已经深刻掌握领域模型和技术架构分离的关系。
能否这样，Domain里面的业务方法都主要产生业务事件，这些事件产生后都由Application的监听器接收后判断使用Application的那种或哪些Service来完成。Application的Service如果需要做持久化操作，就注入Repository或者DAO进行持久化。
比如注册业务：
User要做的就是填好自身资料，提交注册请求，转化成代码就是给自己的属性赋好值，然后触发“注册”事件。
系统要做的是对User的注册事件提供服务，所以Application的某个Service提供了“注册”的服务方法，来处理User的这个事件。这个Service如果认为需要将User的信息持久化，以免丢失，就调用持久层进行辅助操作。
UI层就直接调用User Domain里面触发注册事件的方法。
这样Domain不是贫血的，各层又各施其责了。
以上是我的一点想法，如有误，请各位大侠不吝斧正。
我觉得CRUD不应该是业务操作，所以讨论CRUD到底是放到Service层还是Domain层的意义不大。试想一下，将来的云计算发展到一定程度，我们不再使用自己的数据库来持久化对象，而是直接扔到云里，对象关系映射这一过程直接对我们透明，反正进去出来都是对象，对象在我们的系统中履行其职责或改变自己的状态。。。。
创建行为如果有较丰富业务意义，以放入domain模型为好，被创建出的对象只有在domain context中才易于交互。
最简单的方式，static 方法。
CRUD放在Domain中, 那不是ActiveRecord么?