存储过程应作为性能优化手段，而非架构原则

存储过程因为和数据库运行在同一个进程里，省去了跨进程调用的开销，常常是最快的方案；但代价同样明显——大多数存储过程环境缺乏良好的结构化机制，而且一旦使用就意味着应用被绑死在特定数据库厂商身上（Oracle允许在数据库进程里跑Java程序算是一种缓解思路，等于把整个领域逻辑层塞进数据库，虽然目前还不能让应用彻底摆脱厂商绑定，但至少降低了迁移代价）。正因为这些模块化和可移植性的顾虑，多数人在实现业务逻辑时会尽量避开存储过程，作者本人也基本认同这个立场——除非确实有很强的性能诉求（现实中这种情况其实并不罕见）。作者给出的具体做法是：只有当性能问题真实存在时，才把领域层里某些方法转换成存储过程实现，而且要把这当成一次”清除性能瓶颈”的优化步骤来对待，而不是当成一项从一开始就该遵循的架构原则——换句话说，默认设计不依赖存储过程，等到性能实测确有需要时，再有针对性地把特定方法下沉进数据库。至于具体访问方式，作者并没有”用存储过程”还是”用常规SQL”的强烈偏好，也不认为存在特别强的理由必须选哪一边；真正在意的是无论走哪条路，都应该用同样的模式把数据库访问统一隔离起来，不让这个技术细节渗透扩散到整个代码库里。