架构制图：工具与方法论( 四 )

本文插图
SOLID 原则是一套比较经典且流行的架构原则（主要还是名字起得好）：

单一职责：与 Unix 哲学所倡导的“Do one thing and do it well”不谋而合；
开闭原则：用新增（扩展）来取代修改（破坏现有封装），这与函数式的 immutable 思想也有异曲同工之妙；
里式替换：父类能够出现的地方子类一定能够出现，这样它们之间才算是具备继承的“Is-A”关系；
接口隔离：不要让一个类依赖另一个类中用不到的接口，简单说就是最小化组件之间的接口依赖和耦合；
依赖反转：依赖抽象类与接口，而不是具体实现；让低层次模块依赖高层次模块的稳定抽象，实现解耦。

此外，我们做架构设计时也会尽量遵循如下一些原则（与上述 SOLID 原则在本质上也是相通的）：

正交性：架构同一层次拆分出的各组件之间，应该尽量保持正交，即彼此职责独立，边界清晰，没有重叠；
高内聚：同一组件内部应该是高度内聚的（cohesive），像是一个不可分割的整体（否则就应该拆开）；
低耦合：不同组件之间应该尽量减少耦合（coupling），既降低相互的变化影响，也能增强组件可复用性；
隔离变化：许多架构原则与模式的本质都是在隔离变化 —— 将预期可能变化的部分都隔离到一块，减少发生变化时受影响（需要修改代码、重新测试或产生故障隐患）的其他稳定部分。

2. 架构模式（patterns）

本文插图
架构模式（architectural patterns）与我们常讨论的设计模式（design patterns）并不是一码事，但如果仅从“模式”这个角度去解读，两者的理念都是一致的：针对给定上下文中经常出现的问题的通用、可复用的解决方案。最主要的区别在于，架构模式会更高维抽象和偏全局整体（毕竟是运用在架构设计层面）。
常见的架构模式，既包括一些传统模式（e.g. 分层、C/S、MVC、事件驱动），也包括一些新兴玩法（e.g. 云原生、微服务、Serverless）。不同模式有不同的适用场景，没有哪一种模式能通杀所有需求。成熟的架构师应该像一个冷静到冒得感情的杀手，永远只会客观地评估和选择最适合当下的解决手段，即使那么做会显得简单乏味；相反，不成熟的架构师，一心总想着搞事情（e.g. 强行套用微服务架构），而不是真正搞定问题。
怎么描述你的架构设计？
有了良好的架构设计，万里长征之路就已经走了一大半。就像是青年导演第一次遇上好剧本，心潮澎湃两眼放光，仿佛已经预见了电影上映后的票房盛况。当然，剩下的一小半路，并不会如想象中那么平坦 —— 同样的剧本，不同导演拍出来会有质一样的区别。好的“最佳导演” ，即使面对不是“最佳剧本”的剧本，也有能力拍出“最佳影片” 。同样，好的架构师，也应该有能力描述好一个不错的架构设计；即使做不到为精彩的内容加分，也不应该因为形式上没描述好而丢分，否则就会像高考作文丢了卷面分一样憋屈和心酸。
1. 架构描述的意义

本文插图
为什么要描述架构？让它只存在我深深的脑海里不行吗？西方人有句谚语：好记性不如烂笔头。任何没有持久化的东西都是易失的（volatile），就跟内存一样。另一方面，就如前文所述，架构是沟通协作的基础，不通过架构描述（Architecture Description）沉淀下来让所有项目干系人都能看到，那就失去了沟通和传播的唯一载体。
根据个人观察，大家对“架构需要描述”这一点都没异议，所以绝大部分项目都或多或少会产出一些有模有样的架构描述文档。但“有架构描述”和“有好的架构描述” ，这之间的鸿沟是巨大的，甚至比“没有”和“有”之间的差别还大。如果你也跟我一样，饱经沧桑阅尽无数架构文档，曾拍手叫好心怀感激过，也曾拍着大腿愤怒不已过，应该也能感同身受。