以后关于这个话题， 零碎但有些价值的讨论统一更新至此帖， 有一定内容了再定期整理。
原帖： 关于业务层代码的组织
回复：
你说的稍微有点简略，不过如果你指的业务操作是数据库相关操作的话：这个问题1年前干嘴仗的结果好像说的很清楚了。
CRUD这类操作不属于BL的范畴，应该放入边界对象里； 对象是否贫血， 要看对象是否真的存在自身的业务逻辑。那种认为相关数据操作应该在对象身上就更面向对象的说法，实际上是没真正学过这方面知识的人的一知半解。
不过大嘴Fowler的书里ActiveRecord等两个方式的一个表现出来的特征就是CRUD在对象上（有时通过基类搞定），这种设计很多时候也是行之有效的； 同时是不少ORM/半ORM工具箱所采取的做法之一(虽然我对ORM极端不感冒)。不过， ActiveRecord的实质还是处理行数据等操作，其对象形式只是一个伪装； 以我的观点，恰恰是不那么干净的设计，这样的对象干脆就叫混血对象吧。
另外， ActiveRecord...，我有时候真想不通能给咱带来什么好处。难道Object.Delete()打起字来比较爽? 所以我个人觉得你这种做法很不错， 只是我不喜欢代码生成的方式 :P
同时，我认为如果是彻底贫血的对象， 可以好好考察一下它是否真有必要以确定为某一具体型别的对象的面目出现； 而不是反过来对该型别的对象缺乏操作耿耿于怀， 恨不得把所有和它沾边的事情都交给它负责。
资料：
别在领域模型迷失了自己，在当前讨论的这个论题中，我们着重要把握的是找准“系统边界”； 比如，对于该文中的“域控制器”， 我们应结合上下文去体会其角色， 就不难理解设计对象时的要点了。
还有一些其他的素材，包括思归在一些主角的博客里的留言也很有画龙点睛的作用(以至于到现在还有印象)，一时收集不全了，慢慢找吧。