lazygophers/architecture-design

architecture-design — 正交分解架构方法论

架构的本质不是画框架图, 而是把业务系统正交分解为相互独立、互不耦合的模块。复杂度的唯一根本解是分解, 分解的质量标准是「正交」(改 A 不影响 B)。本 skill 把这套框架落地为可执行的设计/评审流程。

核心理念(一句话)

架构 = 对业务系统的正交分解。 产物 = 「一个尽可能小且稳定的核心系统 + N 个彼此正交、可插拔的周边系统」+ 组合它们的接口契约。

设计工作流(6 步, 按序)

| 步 | 动作 | 关键问题 | 详见 | | --- | --- | --- | --- | | 1 | 需求去伪存真 | 「什么样的人 / 在什么场景 / 遇到什么问题」三要素; 剥到本质层, 区分真需求 vs 表层诉求 | references/mental-models.md 模型7 | | 2 | 划稳定点 / 变化点 | 哪些需求维度一定不会变(→ 钉进核心), 哪些会变(→ 周边/接口暴露)。先判「什么不会发生」 | 模型6 | | 3 | 正交分解 | 把业务拆成彼此独立的子业务; 判据是「改 A 不影响 B」, 而非按技术分层切 | 模型1 | | 4 | 定最小核心 + 周边 | 分出业务最小功能集作核心(最小化、稳定), 其余一律下沉为正交周边/插件 | 模型2 | | 5 | 设计接口契约 | 为每个模块定义接口(可用代码/伪代码精确表达)。接口 > 数据结构 > 架构图。过四准则: 最小完备 / 自然正交 / 易用 / 隐藏实现 | references/interface-design.md | | 6 | 修改影响面自检 | 做思想实验: 「加一个典型新功能, 要碰几个文件、改几行核心代码?」理想 = 核心 0 改动(或 ≤1 行)+ 新增一个独立周边文件 | 模型3 |

🔴 CHECKPOINT(交付设计前): 步骤 5 必须产出精确的接口定义 + 核心数据结构(必要时直接写代码), 不接受只有架构图。架构图不精确、有歧义, 只能做辅助说明。接口才是团队共识的精确载体。

八个心智模型(速查)

| # | 模型 | 一句话 | | --- | --- | --- | | 1 | 正交分解 | 架构即把业务正交分解为互不耦合的模块(改 A 不影响 B) | | 2 | 最小核心 + 正交周边 | 复杂度靠「往周边加功能」而非「改核心」来增长 | | 3 | 修改影响面量化 | 架构好坏 = 加一个功能要改的处数/行数; 越分散越差 | | 4 | 接口 > 数据结构 > 架构图 | 接口是业务的抽象 + 团队共识的精确载体 | | 5 | 开闭原则应对变化 | 软件工程是「关于变化的学问」; 与其改模块, 不如加新业务 | | 6 | 预判「什么一定不会发生」 | 防过度设计的唯一刹车; 比预测会发生什么更重要 | | 7 | 需求三要素 | 真需求 = 什么人 / 什么场景 / 什么问题 | | 8 | 信息世界全栈构建 | 从底层硬件地基到业务顶层, 架构师「在心中重建整个系统」 |

每个模型的应用方式与失效边界见 references/mental-models.md。

判断架构优劣(四准则 + 可操作判据)

评一个架构方案好不好, 过四条准则: KISS(简单, 业务语义无歧义)/ Modularity(着眼模块而非框架)/ Testable(能方便测试 = 低耦合)/ Orthogonal Decomposition(正交分解到位)。

下表是从模型里抽出的「如何判断 / 如何度量」可操作判据, 评审时逐条对照:

| 判据 | 方法 | | --- | --- | | 核心系统纯洁度 | 伤害值 Σ log₂(修改行数+1); 处数越多越糟, 每处压到改 1 行 | | 模块耦合度 | Σ log₂(符号出现次数+1) × 不成熟度系数; 只能对比相同功能的两个方案 | | 是否过度设计 | 「不会发生的事你为它做足了准备」= 过度设计 | | 何时才抽象依赖 | 仅「多选择 / 解除重依赖 / 可选组件」三种情况, 否则直接依赖 | | 是否真需求 | 还原到不带任何技术假设的「根源需求」; 用户反馈常已带方案 | | 需求是否该收敛 | 某子类需求发散无法收敛 → 团队必须重新推敲响应姿势 | | 是否真·全局功能 | 能在统一入口处理 / 只给辅助函数 → 不算全局功能, 别特殊对待 | | 接口是否够好 | 用真实代码把所有用户故事串一遍能否跑通(代码即文档) | | 是否该局部重构 | 基于伤害值客观判断, 且已熟悉该块业务, 非主观厌恶 | | 基础库是否可依赖 | 先评模块「规格成熟度」, 实现问题交给时间 |

⚠️ 伤害值/耦合度公式无物理含义、不可跨功能比较、只覆盖静态依赖(不含运行时调用次数), 用于同功能两方案的相对比较, 不是绝对评分。

Worked example(把 6 步套到一个样例)

需求: 「给一个画图程序加功能」。

1. 需求三要素: 用户=设计师 / 场景=画矢量图 / 问题=高效创建·编辑·导出图形。根源需求是「编辑图形」, 不是「支持 PNG 导出」(那是用户自带的方案)。
2. 稳定点/变化点: 稳定点=图形文档模型(点/线/形状的增删改) → 核心; 变化点=导出格式(PNG/SVG/PDF)、Undo/Redo、剪贴板 → 周边/接口。坐标系: 站在「画图程序」判断, 不是站在「导出器」。
3. 正交分解: 文档模型 ⟂ 渲染 ⟂ 导出 ⟂ 历史(Undo) ⟂ 剪贴板。验证正交: 加一种导出格式不该动文档模型。
4. 核心 + 周边: 核心=文档模型(最小功能集: 图形 CRUD + 遍历)。周边=各导出器、各渲染后端、历史、剪贴板, 全部插件化。
5. 接口契约: 核心暴露 DocumentDOM(遍历图形的只读接口)。导出器 Exporter.export(doc DocumentDOM, w io.Writer)——参数用 io.Writer 而非 *os.File(LKP, 顺带支持剪贴板/内存)。用真实代码把「导出 SVG」「复制到剪贴板」两个用户故事串通验证。
6. 修改影响面自检: 加「导出 PDF」= 新增一个实现 Exporter 的周边文件, 核心 DocumentDOM 0 改动 → 伤害值 0, 设计合格。
   • 反例对照: 若加 PDF 要在文档模型里塞 if format==pdf → 核心被迫改动, 伤害值飙升, 重新分解。
   • Undo/Redo 不在「发生处」解决 → 下沉到数据层(多版本), 一并解决快照/异步(见 §A)。

失败处理(触发 → 一线 → 兜底)

| 触发 | 一线修复 | 仍失败兜底 | | --- | --- | --- | | 子业务无法正交(强一致事务/共享状态本质耦合) | 用「全局性功能」处理横切关注点: 抽象核心接口让全局功能反向依赖(references/decomposition-and-refactoring.md §A), 而非塞进核心 | 承认此处有不可消除耦合, 显式标注为已知技术债, 不制造虚假边界 | | 需求理解未收敛, 接口拿不准 | 接口本身是变化点 → 延后冻结, 先用最薄的探索性接口 | 标注「探索期接口, 待业务收敛再固化」, 不过早锁死错误抽象 | | 「什么不会变」在新领域误判率高 | 保守留口或延后决策, 不赌 | 标注高不确定维度, 用迭代/重构应对而非一次设计到位 | | 核心已老化, 改动处处掣肘 | 进入重构而非继续打补丁; 「不断重新审视边界」 | 边界非一次划定永久不变; 重新正交分解 |

适用边界

本方法在成熟、约束清晰的领域最可靠。在新领域/快速演化领域(如早期探索性产品), 「预判什么一定不变」误判率高, 应保守留口或延后决策。方法的价值在判断逻辑与可操作判据(三要素 / 四准则 / 修改影响面度量), 不在套用固定结论。

参考集(按需读)

| 文件 | 用途 | | --- | --- | | references/mental-models.md | 八个心智模型详解(应用/失效边界 + 影响面公式)+ 决策启发式 | | references/interface-design.md | 两种接口语义(KISS / 最小依赖)+ 接口/数据结构/架构图优先级 + 接口反模式 | | references/decomposition-and-refactoring.md | 进阶: 全局功能/横切、架构范式、边界审视、架构老化与重构(六步)、共识确认 |