
























将系统划分为职责完全独立、互不依赖的模块(正交维度),
各模块通过统一控制总线 / 中介协作,
一个维度的变化不影响其他维度。
核心理念:
“变与不变分离,变化之间互不影响”
┌────────────┐
│ 控制总线 │
└─────┬──────┘
┌────────┼────────┐
┌──▼──┐ ┌──▼──┐ ┌──▼──┐
│模块A│ │模块B│ │模块C│
└─────┘ └─────┘ └─────┘
| 优点 | 说明 |
|---|---|
| 低耦合 | 模块独立演化 |
| 高内聚 | 单一职责清晰 |
| 易扩展 | 新增模块不改动旧系统 |
| 易维护 | Bug 定位、替换成本低 |
| 高复用 | 通用模块跨项目使用 |
| 缺点 | 说明 |
|---|---|
| 设计成本高 | 需要提前识别正交维度 |
| 初期复杂 | 小项目显得过度设计 |
| 中介性能损耗 | 总线/事件机制带来开销 |
| 易误用 | 强依赖伪装成正交 |
| 架构 | 核心思想 | 对比正交架构 |
|---|---|---|
| 分层架构 | 上层依赖下层 | 层间强依赖,不够正交 |
| 微内核 | 核心 + 插件 | 正交架构常借鉴其思想 |
| 微服务 | 进程级解耦 | 正交是逻辑级,微服务是部署级 |
| 模块化单体 | 模块拆分 | 若无真正解耦,仍非正交 |
正交软件架构的本质是:
用“完全解耦的可组合模块”,换取系统的长期演进能力。
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。