软件架构设计通常会考虑业务功能（客户需求）和非功能性需求（易用性、可靠性、移植性、性能、扩展等），容易忽略开发人员的自我感受。架构/框架解决不了所有问题，开发人员的主观能动性极为重要。实际上软件框架的用户是开发人员而不是最终用户，保证开发人员稳定性、积极性、好招聘是一个框架的非功能性需求。
框架最终形态最好为：
1、提供了基础框架（方便使用，规格一致）。定下系统基本基调，实现基本功能，考虑扩展和性能等非功能性问题。
2、不过度封装（灵活，自主；不易受控）。不易受控是双刃剑，可以发现/提升开发人员能力（有潜质的开发人员）、可以降低产品质量，需要和产品管理结合起来解决此问题。
3、自动化机制（元数据，自动代码生成，单元测试，并发测试等）。自动和智能是节省时间和保证质量的利器，可靠性方面计算机比人可靠。
4、配置和约定（配置和约定并存，细节走约定、框架走配置）。配置可以解耦，依赖配置的系统扩展性比较好。大量配置会让人不满，开发人员介入的部分最好走约定。
5、使用主流技术（依赖其他框架并可低成本替换）。
如何把握度：哪些封装哪些人为处理？
1、站在开发人员的角度思考，设身处地替别人着想是一种素质。开发人员注重自我成长、成就感、不爱受约束。
2、个性化少部分比较通用，框架处理；开发人员参与部分最灵活，需要区分可变性与不变性，不变性做成库，可变性自由发挥。before_do/框架do/after_do方式对于大项目不好，容易限制个人发挥，也不利于扩展。
3、引入主流技术，让开发人员接触使用。使用主流技术/新技术是开发人员所注重的。在框架级别需要确保主流技术可框架级替换和细节级自动化替换，除了计算机，谁也不想做第二遍。