致知录
第 III 卷 · 第 12 篇 · Engineering · 1970.01.01

正交性原则：让系统各部分"独立变化"

工程 · 1970.01.01 · 7 分钟阅读 · 1,747 字
目录 · 13
一、什么是正交性二、正交性的常见场景三、2 步框架：实现正交性第 1 步：识别依赖第 2 步：消除不必要的依赖四、正交性的好处好处 1：可维护性好处 2：可测试性好处 3：可复用性五、练习题单选题案例分析反事实思考题
"好的设计：改一个不影响另一个。"

预计时间：15 分钟读 + 15 分钟做习题 = 30 分钟。

本课承诺
读完这节课，你将掌握：
① 正交性 (Orthogonality) 的精确定义；② 如何让系统各部分独立变化；③ 正交性的 2 步框架。

一、什么是正交性

正交性：系统中的两个部分独立变化，互不影响

正交：改 A 不影响 B，改 B 不影响 A
不正交：改 A 影响 B，改 B 影响 A

芒格式翻译
"改一个影响另一个" = 最笨的设计（混乱）。
"改一个不影响另一个" = 最聪明的设计（清晰）。
芒格说："好的设计：改一个不影响另一个。"

二、正交性的常见场景

场景正交不正交
前端HTML/CSS/JS 分离样式写在 HTML 里
后端Controller/Service/Repository 分离业务逻辑写在 Controller 里
数据库Schema/Query/Index 分离查询写在 Schema 里
测试Unit/Integration/E2E 分离所有测试写在一起
部署Build/Deploy/Monitor 分离所有流程写在一起
正交性的陷阱
不是所有事都需要用正交性！
1. 过度正交：拆得太细，失去整体视角
2. 错误正交：把必须连接的部分断开
3. 忽视依赖：部分之间有依赖，但你没发现
平衡：正交性是"逻辑标准"，不是"物理标准"。

三、2 步框架：实现正交性

第 1 步：识别依赖

先明确：系统中各部分之间有哪些依赖？

案例：电商系统
依赖：OrderModule 依赖 PaymentModule

结论：OrderModule 和 PaymentModule 不正交。
案例：社交系统
依赖：MessageModule 依赖 NotificationModule

结论：MessageModule 和 NotificationModule 不正交。

第 2 步：消除不必要的依赖

再消除：系统中各部分之间不必要的依赖。

案例：电商系统
消除前：OrderModule 直接调用 PaymentModule
消除后：OrderModule 通过接口调用 PaymentModule

结论：OrderModule 和 PaymentModule 变得正交。
案例：社交系统
消除前：MessageModule 直接调用 NotificationModule
消除后：MessageModule 通过事件通知 NotificationModule

结论：MessageModule 和 NotificationModule 变得正交。

四、正交性的好处

好处 1：可维护性

修改一个部分，不影响其他部分

好处 2：可测试性

每个部分可以独立测试

好处 3：可复用性

一个部分可以在多个地方复用

芒格式翻译
"改一个影响另一个" = 最笨的设计（混乱）。
"改一个不影响另一个" = 最聪明的设计（清晰）。
芒格说："好的设计：改一个不影响另一个。"

五、练习题

单选题

1

正交性是指？

2

「改一个不影响另一个「体现了？

3

实现正交性的第一步是？

4

「OrderModule 直接调用 PaymentModule「属于？

5

「OrderModule 通过接口调用 PaymentModule「属于？

6

「HTML/CSS/JS 分离「属于？

7

「样式写在 HTML 里「属于？

8

正交性的好处不包括？

9

「修改一个部分，不影响其他部分「属于？

10

正交性是「逻辑标准「还是「物理标准「？

案例分析

C1

C1. 案例：团队要做电商系统，用正交性，应该先做什么？

C2

C2. 案例：团队要做社交系统，用正交性，应该先做什么？

C3

C3. 案例：团队要做工具系统，用正交性，应该先做什么？

反事实思考题

T1

T1. 反事实：如果团队没有用正交性，改一个影响另一个，最可能的结果是？

T2

T2. 反事实：如果团队过度正交，拆得太细，最可能的结果是？

下一步：Lesson 0013 · 事前验尸——如何在项目开始前就发现潜在问题。