开工大吉，重温下架构设计六大原则
今天是正月初七，我还请假在家，刚刚读了《银河帝国》，读到马洛解决了谢顿危机，成为继哈里谢顿、赛佛哈定之后的第三位英雄。春节过得还不错，休息了、陪伴家人了、学习了、思考了。
重温下架构设计六大原则。
1. 单一职责原则。一个类只能有单一的职责，不同的类各司其职。如果一个类有两个及以上的职责，说明设计有问题，对业务、架构、模型、扩展的认识有盲区。与 DDD 思想类似，设计代码必须有确定性、有明确的边界，扩展一下就是 DDD 中的子域划分。
2. 开放封闭原则。对扩展开放，对修改封闭。这里可以有两种实现方式，一种是用继承或组合的方式来扩展类的功能而不直接修改类的代码，另一种是使用策略模式通过新的策略定制业务实现而不修改原来的代码。开放封闭必然涉及到边界，边界以内是封闭的，边界以外是可以（非必然）开放的。
3. 里氏替换原则。继承、多态的更高层次的理解，使用接口、父类来传递引用，实际运行时可以是父类实例也可以是子类实例。这个原则是实现开闭原则的重要方式之一，使用非常普遍，只要有足够的抽象，就一定无法避免。
4. 最少知识原则/迪米特法则。通俗说，知道的越多，死的越快，不多问、不多想、不多说。在代码中，任何知识的传递都会引入新的复杂性，比如需要加入参、加依赖。上层在业务范围内尽量少感知底层实现，底层也不要想那么多非要去了解外面的逻辑。
5. 接口隔离原则。一个类与另一个类之间的依赖性，应该依赖于尽可能小的接口。不依赖不需要的接口，有利于代码的长期维护和重构。大的接口要根据用途拆分成小接口，小接口的方法数量也要好好考虑，和单一职责、最少知识有点相似。
6. 依赖倒置原则。这个原则非常有用，能够指导出架构内核的设计，尤其是对流程的抽象。spring IOC 就是典型的依赖倒置，代码可以有依赖，但是运行时到底是哪个实例，代码没有必要关心。在架构内核的抽象开发中，依赖倒置是最重要的原则，只有这样才能进行足够的抽象和沉淀，才能让业务进行扩展。
以上 6 个原则，有一个共同点，就是高内聚低耦合，满足 6 个原则能够设计出稳定可靠的架构。不过这是参考，具体落地还要具体情况具体分析。
