框架是工具而非信条，围绕用例的架构才能脱离框架测试

[[尖叫的架构目录结构该喊出用例而非框架名字]]的落地需要对框架保持警惕：框架本身可以非常强大有用，但框架作者往往对自己的作品抱有近乎信仰的执念，写出的使用手册常常是从”如何成为该框架虔诚信徒”的视角展开，甚至框架使用者写的教程也带着这种传教士腔调，宣称某个框架能包揽一切、超越一切、解决一切问题——这种论调不该被照单全收，任何框架都该被带着怀疑审视：用它确实可能有帮助，但成本是什么？该怎么权衡使用方式、怎么保护自己不被框架反过来主导架构？始终要记住关注点应该落在系统用例上，而不是让框架牵着架构设计的鼻子走。这种”围绕用例、警惕框架”的架构设计带来一个可验证的检验标准：可测试性。如果架构确实是围绕用例展开、并对框架使用保持谨慎，那么针对这些用例的单元测试就应该能在完全不依赖任何框架的情况下运行——测试时不需要启动Web服务、不需要连接数据库，测试对象应该只是一个简单的业务实体对象，没有任何与框架、数据库相关的依赖，靠用例对象来调度业务实体对象，确保所有测试都不牵涉框架。这也决定了新程序员第一次接触系统源码时该看到什么：应该先了解系统的用例（比如”这是一个医疗系统”），而不是先关心它的交付方式——面对”我看到了模型代码，但视图和控制器在哪”这类问题，恰当的回答是”我们现在先不考虑这些细节问题，回头再来决定”，因为这些细节本就该被推迟决策。