例子1、银行帐号Account：
一个经常引起争论的问题就是，deposit/draw方法到底应该建模到 Account中还是建模到AccountManager(对一个银行出纳员的建模)中。
我觉的将deposit/draw建模到AccountManger中是反映现实的，因为Account反映到现实世界就是一个没有行为能力的实体，而出纳员才具有行为能力。
例子2：选课的学生Student
对学生建模的时候，enroll(选课行为)毫无疑问应该建模到类Student中。
除此之外，我们假设每个学生有一个考察级点，可以根据这个学生的表现增加或者减少级点，而我们就遇到同例1中提到的deposit/draw一样的问题，就是增加级点的方法addScore/减少级点的方法reduceScore建模到Student中还是StudentManager中，个人认为，同于例1，应该建模到StudentManager中而不是Student中。
总的来说，方法到底建模到那个Class中，就根据这个方法是否是这个Class自发的行为。譬如，Account的deposit/draw就不应该建模到Account中，但是实践中，建模到Account中，往往会带来一些好处，至于什么好处，Martin的《Domain Logic and SQL》非常全面的分析过了。所以，我感觉，Martin举的例子中，贫血的Domain Model是乱扣大帽子。
本来就没什么Transaction Script，没什么贫血的Domain Model，Martin非要将一种正确的模型叫做“贫血的Domain Model"，而将没有反映现实世界的、但是有一定实践价值的模型起一个风度翩翩的名字。
为什么有人经常提到贫血的Domain Model？我觉的，可能很多应用是以数据为中心的，所以，建模的时候，习惯性地思维定向到数据上，建模出来的类完全是DB Entity的反映。而正确的思路，应该针对整个系统进行对象建模，不要一开始就考虑持久化的问题。