如何从业务到系统的“贫血”和“充血”

“根据四色原型的分析方法，我们可以得出：某个“人”以图书借阅者的角色向图书馆借书。从这里我们可以得出三个角色：1）借阅者（Borrower）；2）被借的图书（BorrowedBook）；3）图书馆。”
这样做有没有角色分析过度的嫌疑，我对角色（Role）的理解是权限的集合，更多指的是人在某一上下文（Context）能做什么，毕竟在业务分析中说明人要干什么更自然些。
在这样一个相对简单的用例中，就要思考这么多角色的扮演者对象是谁？这的确是DCI问题的关键，但似乎很难和别人达成共识，比如说我就不认为图书卡是真正的借阅者角色的扮演者，我认为图书管理员才是，或者如楼主说的"很多人所认为的走进图书馆的那个人"！当然这只是一个例子，争论谁到底是“借阅者角色”都不重要，重要的是我们能在借书这一领域对于这些对象能达成一致吗？如果不能自然的达成一致，还需要大量的解释（见楼主的解释说明内容），对于个人对业务的分析或许是有用的（你可以用它来扩充对象的行为，并根据这些分析编写代码），对于领域模型构建则无用。
DCI只不过是把原本是充血模型中对象行为的设定延迟到了所谓的“角色”上，并没有从根本解决如何充血模型中对象行为设定的问题，实际上我认为这些行为也的确很难确定，类职责的分配是OOD中最大的问题，很难说有“银弹”，只能是个别问题个别分析，“一劳永逸”的想靠技术解决行不通。
从另一个角度来看，我倒是觉得“贫血模型”倒是能解决领域模型的构建，毕竟不包括行为只包括属性的对象还是相对稳定的，书也好，图书馆也好，图书卡也好，他们的属性是不会有太大变化的，即使有扩充起来也简单的多。用事务类封装行为，用服务（Services）包装事务，用人扮演的角色操作服务可能和分析出的业务用例更切合一些。我在读DDD时，始终认为Eric Evans的领域模型本意还是更贴近“贫血模型”（当然这是我个人的看法）。
对业务分析的越深入，可能越觉得自己对领域模型把握的越透彻，就很容易在对象中添加“个性化”的行为，尤其是写程序的人还进行业务分析，如果跳出来，让一个不懂编程的人（纯业务人员）或一个不懂业务的人（纯程序员）来看这个领域模型，他们都是很难理解的。领域模型一旦失去了沟通的意义，往往就僵化了，失去作用了，如果只是分析人员懂，那就可能出现偏差和错误，最终导致谁都不愿碰那个领域模型。
以上是个人的一些看法。
另外，“贫血”和“充血”之争每隔一段时间都会重来。但有些讨论过多的关注技术层面，多在数据持久化、DTO、服务层方面纠结（当然这也很重要）。我更关心的是如何从业务到系统的“贫血”和“充血”，而不是系统的实现技术。