架构设计原则

基于对架构本质的理解，关于架构设计业界有一些非常好的基本原则。

SOLID原则

《架构整洁之道》一书中提到的SOLID原则（下面各个原则的首字母）。这些虽然是面向服务设计的原则，但对于架构设计同样适用。

单一职责原则（Single Responsibility Principle）

基于康威定律的启示，每个模块有且只有一个被更改的理由。在架构设计过程中，特别是在抽象和封装过程中，应尽量设计得没有互相重叠（如相关的流程、服务功能），有明确的使用者和操作者，比如订单核心能力的最终修改，需要聚集在一个单独共用的模块上，这样职责清晰，也便于后续架构演进。

开闭原则（Open Closed Principle）

企业应对扩展开放，对修改关闭。也就是说，企业的架构要尽可能考虑扩展性，减少不必要的修改，比如企业可以采用模型的扩展、服务接口的继承、流程的编排、能力的组合等方式，通过分层和扩展解决用户不断变化的诉求，这样也有利于快速支撑业务发展。

里氏替换原则（Liskov Substitution Principle）

任何基类可以出现的地方，子类也可以出现，二者是“IS-A”关系，如绵羊是羊的一个种类。企业在进行架构设计时，如果有些架构是相互继承的，则要关注其中的继承关系，如从应用架构到具体部署架构的分解过程。

另外，我们通常把核心的原子能力进行最小集的封装，在架构扩展设计中，任何对原子能力的扩展都需要维持原子能力的定位。

迪米特法则（Law of Demeter）

如果两个模块无须直接通信，就不应当发生直接相互调用，可以由第三方转发。在架构设计过程中，要尽可能减少不必要的相互调用，降低模块之间的耦合度，提高相对独立性。

接口隔离原则（Interface Segregation Principle）

在架构设计过程中，企业需要避免不必要的依赖，也就是最小化组件（或模块）之间的依赖度和耦合度。在架构设计中，主要要求尽量保持组件之间的耦合，这样既可以降低相互的变化影响，也可以增强组件的可复用性。架构的设计尽量不要依赖不必要的东西，比如业务架构应聚焦能力、流程，应用架构应聚焦领域、服务，技术架构应聚焦技术组件支撑等，避免修改一种架构要连带修改其他分层的架构。

依赖反转原则（Dependence Inversion Principle）

企业的高层策略不应该依赖底层细节，而底层细节应该依赖高层策略。比如，当设计服务的时候，下层服务不应该修改上层服务，如电商中的订单分层高于商品和促销，在订单层级可以修改商品库存、促销状态等，而反向操作是不允许的。

其他经典架构设计原则

业界还有一些比较经典的架构设计原则。

正交性

架构设计要考虑全面，保持正交，职责独立，边界清晰，没有重叠。这类似于结构化思维中的MEMC（Mutually Exclusive, Collectively Exhaustive）法则，即相互独立，完全穷尽。

高内聚

同一层架构内应该是高度内聚的，就像一个不可分割的整体，否则就应该拆开。

低耦合

不同层的架构间应该尽量降低耦合度，这样既可以减少相互的变化影响，也可以增强组件的可复用性。

简单适用

架构并不是一成不变的，规划要全面，落地时要讲究合适原则和简单原则，应以符合当前业务发展需要为主要目标，而不是单纯为了设计架构而设计架构。