远程外观数量应少而粗，而非每用例一个

远程外观是建立在大量细粒度对象之上的粗粒度门面，本身不含任何领域逻辑，唯一职责是把粗粒度方法调用转换成对底层细粒度对象的多次调用（比如一个批量的setAddressData调用，外观内部还是照常逐个调用地址对象原有的setter方法，所有校验和计算逻辑仍然留在细粒度对象里）。围绕外观的粒度大小，存在两种流派：有人偏爱非常小的远程外观，甚至每个用例都单独建一个；作者本人的取向明显相反——倾向于用更粗的结构、更少的外观数量，一个中等规模的应用往往只需要一个远程外观，即便是大型应用，作者通常也只用六个左右——这意味着每个远程外观内部会包含相当多的方法，但作者认为这不是问题，因为这些方法本身都很简单。外观里出现大量方法、而这些方法在底层其实调用的是同一批基础操作，这完全正常且很常见——外观设计的目的是简化外部客户的使用体验，不是简化内部系统结构；因此即使两个外观方法在底层殊途同归，只要客户进程把它们当成两条不同的命令来用，它们在外观层面就应该被设计成两个不同的方法。可迁移启发：给一层对外接口做粒度切分时，”按用例逐一拆分接口”看似清晰，实际上会让接口数量随用例数量线性膨胀；更务实的做法是反过来想——先按整体应用的自然边界圈出少数几个粗粒度的外观，接口内部允许有很多方法，只要每个方法本身足够简单，接口数量的克制比接口内部方法的数量更值得优先考虑。