1. 每个模块都应该只做一件事；确保一个函数只完成一个功能；任何模块都应该只对某一类行为者负责；需要将服务不同行为者的代码切分开；
2. 设计良好的软件应该易于扩展，抗拒修改；我们应该更关注的问题是，满足新的要求需要更改多少旧代码，一个好的架构设计师应努力将旧代码的修改需求量将至最小；
3. 如果A组件不想被B组件上发生的修改所影响，那就应该让B组件依赖A组件；
4. 软件系统不应该依赖其不直接使用的组件；OCP的主要目标是让系统易于扩展，同时限制每次被修改所影响的范围；
5. LSP是指导接口与实现方式的设计原则，即可替换性。
6. 如果依赖于不需要的东西，都会是有害的；任何层次的软件设计如果依赖了它并不需要的东西，就会带来意料之外的麻烦。
7. 依赖关系中应该多引用抽象类型，而非具体实现；
8. 我们应该主要关注那些会经常变动的具体实现模块，这些模块是不停开发的，也就经常变更。
9. 接口比实现更稳定；应当花费大非精力来设计接口；
10. 应在代码中多使用抽象接口，尽量避免使用那些多变的具体实现类；不要在具体的实现类上创建衍生类；不要覆盖包含具体实现的函数；应避免在代码中写与具体实现相关的名字；
11. 抽象接口组件中包含了应用所有的高阶业务规则，而具体实现组件中则包含了所有业务规则所需要做的具体操作及其相关细节信息；
12. DIP：代码依赖方向永远是控制流方向的反转
13. 依赖守则：单向依赖关系
14. solid用来指导如果将砖块砌成墙和房间；组件构建原则指导如何将房间组合成房子；
15. 软件复用的最小粒度应等同于其发布的最小粒度；一个组件不能由一组毫无关联的类和模块组成，他们之间应该有一个共同的主题或大方向；
16. 对大部分程序来说，可维护性的重要性远远高于可复用性；
17. 将由于相同原因而修改，并且需要同时修改的东西放在一起。将由于不同原因而修改，并且不同时修改的东西分开；
18. 不紧密相连的类不应该被放在同一个组件里；
19. 组件依赖关系图中不应出现环；团队反馈周期越长，研发质量自然就会越差；