正交软件架构（Orthogonal Software Architecture）笔记
一、什么是正交软件架构
将系统划分为职责完全独立、互不依赖的模块（正交维度），
各模块通过统一控制总线 / 中介协作，
一个维度的变化不影响其他维度。
核心理念：
“变与不变分离，变化之间互不影响”
二、主要特点
1. 正交性（核心）
- 模块之间：
- 无循环依赖
- 不互相感知具体实现
- 修改一个模块 → 不影响其他模块行为
2. 统一协作中介
- 控制总线（Control Bus）
- 事件总线（Event Bus）
- 插件容器 / 微内核
┌────────────┐
│ 控制总线 │
└─────┬──────┘
┌────────┼────────┐
┌──▼──┐ ┌──▼──┐ ┌──▼──┐
│模块A│ │模块B│ │模块C│
└─────┘ └─────┘ └─────┘
3. 高复用 & 可组合
- 模块可在多个系统复用
- 新功能 = 新组合（非修改旧代码）
4. 易测试、易替换
- 可单独单元测试
- 可热插拔替换实现（如存储、算法）
三、优点 ✅
| 优点 | 说明 |
|---|---|
| 低耦合 | 模块独立演化 |
| 高内聚 | 单一职责清晰 |
| 易扩展 | 新增模块不改动旧系统 |
| 易维护 | Bug 定位、替换成本低 |
| 高复用 | 通用模块跨项目使用 |
四、缺点 ❌
| 缺点 | 说明 |
|---|---|
| 设计成本高 | 需要提前识别正交维度 |
| 初期复杂 | 小项目显得过度设计 |
| 中介性能损耗 | 总线/事件机制带来开销 |
| 易误用 | 强依赖伪装成正交 |
五、适用场景 ✅
- 大型复杂业务系统（ERP、金融核心、政务系统）
- 插件化系统（IDE、规则引擎、工作流引擎）
- 多渠道接入系统（Web / App / API / 第三方）
- 需求频繁变更、长期演进的系统
- 对测试性、替换性要求高的系统
六、不适用场景 ❌
- 小型 CRUD 项目
- 极致性能、低延迟系统
- 团队缺乏架构设计经验
七、与其他架构对比
| 架构 | 核心思想 | 对比正交架构 |
|---|---|---|
| 分层架构 | 上层依赖下层 | 层间强依赖，不够正交 |
| 微内核 | 核心 + 插件 | 正交架构常借鉴其思想 |
| 微服务 | 进程级解耦 | 正交是逻辑级，微服务是部署级 |
| 模块化单体 | 模块拆分 | 若无真正解耦，仍非正交 |
八、设计要点（实践建议）
- 先识别变化维度
- 业务规则
- 技术实现
- 外部系统
- 严禁模块间直接调用
- 通过接口 / 事件通信
- 保持模块可独立部署或可测试
- 定期重构，消除隐性依赖
九、一句话总结
正交软件架构的本质是：
用“完全解耦的可组合模块”，换取系统的长期演进能力。