MailProxy案例：用例驱动模块划分的优缺点

世上决策有两种迥然不同的方法：借助经验和借助推理分析。根据功能树切分功能模块、分解上下文图进行分层，属于大刀阔斧、偏重经验的一类；[[用例驱动模块划分的两环节四步骤]]属于密密而织、偏重分析的一类。有意思的是，通过用例驱动设计出的模块划分结构，可能和其他方法（功能模块划分、架构分层）的设计结果殊途同归——比如MailProxy案例中，用例驱动方法最终得到的可能就是一种分层架构。用例驱动方法在MailProxy案例上表现出的优缺点非常鲜明。优点：由简入繁，从研究一个个功能的实现作为切入点，容易上手——面对不太有经验的系统、或特别复杂的系统时，这种方法特别有帮助，因为它不要求架构师一开始就对系统整体有全局判断，只需要先啃透一个个具体用例；用例驱动的设计过程本身还为后续详细设计提供了不少铺垫，因此受到不少”程序组长”的欢迎（用例驱动的设计方法本身就是软件详细设计方法的核心思维之一）。缺点：用例多的时候，从用例到类、再到模块，设计工作量会很大——对于有一定设计经验的系统，书中建议先经验驱动、后用例驱动，而不是一上来就对所有用例做细粒度的用例驱动分析；如果用例驱动方法运用得太死板，还可能掉入”先详细设计、后架构设计”的陷阱——这正呼应了第14.2.2节”解惑2”提到的风险：如果试图研究每一个用例的实现再划分模块，设计如何实现每个用例就没有受到架构的指导和制约，可扩展性、高性能这类整体质量属性也就无从保证了。用例驱动设计过程的优点和缺点都非常突出，这提示架构师应该把它当作工具箱里的一件工具、按场景选用，而不是当成放之四海皆准的唯一方法。