随想之架构的本质
date
Oct 1, 2025
slug
status
Published
tags
架构
type
Post
summary
找到一个“简单”的视角看世界
架构的本质，就是让视角简单点。
这个定义听起来可能有些“草率”，甚至颇有“听君一席话，如听一席话”的味道。但请容我“狡辩”一番——架构设计领域充斥着太多规范化的定义，例如维基百科对软件架构的说明：
软件架构是抽象描述系统的一组结构，以及构建这些结构的规则。这些结构包括：软件要素、要素之间的关系以及它们的属性。
坦白说，我觉得这个定义才是真正的“说了等于没说”，让人看了跟没看一样。
我们之所以需要架构，根本原因在于人的精力是有限的，人脑的“寄存器”数量和容量相当有限。当一个系统本身过于复杂时，我们就容易失去对它的掌控。此时，我们需要某种方式将这个复杂的系统“简单”地组织起来。为什么强调“简单”？因为只有足够简单，才不容易出错；只有足够简单，人才能毫无压力地掌控这个系统。
你可能会觉得我又在说些不负责任的话——系统本身很复杂，架构却要简单地组织它，凭什么？怎么组织？
我的答案是：让每个视角都足够简单。
这本质上是一种分而治之的思想，类似于传统王朝的“分封制”。不同的是，真实王朝中会有起义造反，而计算机世界则不会（毕竟是人就有欲望，而程序没有）。“分封”最大的意义在于让每个层级的视角都保持简单——对于“王”来说，只需要管理“诸侯”；“诸侯”只需要管理“卿大夫”，以此类推。每一个层级的视角都是简单的，可管理的。
接下来，我们可以用经典的SOLID设计原则来印证这个观点：
S - 单一职责原则：一个类应该只做一件事，只有一个引起变化的原因。这一原则直接体现了让对象变简单的思想，每个类只关注自己的职责范围。
O - 开闭原则：对扩展开放，对修改关闭。初看似乎与我们的论点无关，但仔细想想，扩展意味着分离，修改意味着融合。对象的融合会让原对象变得更复杂，特别是当对象本身已经具有一定复杂度时，融合后的对象可能会超出我们的掌控范围，这就是风险的苗头。
L - 里氏替换原则：子类应该能够替换它的基类。这个原则完全是为“分封制”服务的——“王”认为“诸侯”能够承担某种义务，那么具体的诸侯就必须能够承担这种义务。这是保持视角简单的必要保障。
I - 接口隔离原则：接口应该保持独立。这个原则特别有意思——我们不仅要让“王”的视角简单，也要让“诸侯”的视角简单。当“诸侯们”的责任被清晰隔离后，不仅“王”更容易区分和控制，每个“诸侯”自身的视角也变得更加简单。试想，如果“诸侯A”在管理自己辖区时，还需要考虑“诸侯B”辖区的事务，那该有多麻烦？
D - 依赖倒置原则：对象应该依赖接口和抽象类，而不是具体的类和函数。这一点相对容易理解——在“王”眼中，最重要的是“诸侯”的义务，而不是具体的“诸侯”是谁。这个原则与里氏替换原则相辅相成，共同维护着系统的简洁视角。
总结而言，架构的本质就是让每个视角都保持简单，而架构设计的过程，往往就是这种简洁的顶层视角自上而下建立的过程。
