对象臃肿问题：不要过早分离用例特定行为

使用领域模型常见的一个担忧是对象会变得臃肿：设计订单交互界面时，会发现订单的部分行为只在这一个交互场景里用得到——如果把这些职责统统塞进订单对象，订单类就可能被大量只服务于特定用例的职责撑得过于庞大，于是人们开始纠结哪些职责算”通用”该留在订单类里、哪些算”特殊”该挪去事务脚本或表现层本身。但把”具体用例特有的行为”提前分离出去也有代价：分离出去的行为很难被后来的开发者定位到，容易导致有人因为找不到已有实现，索性自己重写一段功能相同的代码，制造冗余、增加系统的复杂性和不一致性。作者给出的经验判断是：对象臃肿实际发生的频率远比人们预想的要低，而且一旦真的发生了，也很容易被发现和修正——基于这个观察，作者的建议是不要提前把具体用例的行为从领域对象里分离出去，而是把它们放在本该属于的对象里，等到对象真的臃肿了再动手修正。可迁移启发：对”可能出现的设计坏味道”（如某个类变得太大）保持警惕是对的，但为了预防一个”发生概率其实不高、发生了也容易修”的问题，提前引入分离带来的确定性代价（冗余代码、定位困难），往往不划算——衡量要不要提前优化，该看这个问题实际发生的概率和事后修复的成本，而不是它理论上”可能发生”这件事本身。