单一职责编程指南

在我们应用OO进行分析设计的时候,又提出了贫血和充血的概念.并产生了很大的争论.结合DDD，在这里,我也谈谈我的想法。 1.贫血模式说白了就是把对象看成是数据的载体.因为它不存在实际的操作动作,只是各种数据的集合.从这个角度,尽管我们设计出来了对象.实质上我们只是在过程式开发模

我在设计中遇到一个问题！而且我想或许大家也会有类似的困惑，还是我多想了抑或是孤陋寡闻。具体问题如下，简化了分析模型利用ctrl（action）接受客户端提交的请求并分配到不同的DS（DOMAIN SERVICE），然后DS调用BO,BO在调用DAO来完成持久化！粗略地看看是没有太大的问题，耦

-->>失血模型 　　MF（Martin Fowler）曾经提出有名的贫血模型或失血模型，让我们好生迷惑和彷徨，他认为实体模型对象中只有弱行为setter和getter方法，没有真正行为，好像缺少血液的人，不和谐了，不少高手又被忽悠了，大谈贫血模型。

充血模型有什么实际的好处么？ 难道就为了好听 完美（数据和行为统一）？ 过于复杂的需求还是用贫血 ,一般需求用充血 ,这样做正确吗？ 项目中用的更多的哪个模型呢。 比较

定义一个巨大的model，把自已历史用到过的方法都封装进去，这样就成了百宝箱了，这种方法行不行得通，请高手们指点!

比如说，User 类中有 用户名，密码！ 现在我想加上个密码保护，是让它以MAP的形式作为User的属性呢，还是创建一个新的类让User类与这个类发生关系！

虽然对UML有些了解，但具体到项目分析设计时，却有一种不知道如何展开的困境。系统中简单的或复杂的逻辑，如果用文字描述，看起来很费劲，且变更管理非常不便。现想用图形来描述。但不知道用什么图形来描述，看到大牛们对什么问题用什么图形来分析手到擒来，真是羡慕不已。