一、核心概念：什么是架构与架构思维
1.1 架构的定义
"雕像本来就在石头里，我只是把不要的部分去掉。" —— 米开朗基罗·博那罗蒂架构是客体——它是事物本身存在的性质，不以人的意志为转移：
- 建筑的架构，无论有没有图纸去表达，它就在那里
- 程序的架构，无论有没有架构文档，它就在那里
- 组织的架构，无论有没有组织架构图，它就在那里
- 流程的架构，无论有没有流程图，它就在那里架构的精确定义：对当前事物本身构成、运行的状态、信息的抽象。 它是我们对所需要解决的问题实例的一种拓扑，包含了所有事物的所有重要信息。通过了解事物的完整架构，任何人都能够掌握当前事物的运行规律，并且能够完整地复制它。
1.2 架构思维的定义
架构思维是主体——描述架构、认识架构、使用架构的思维方式。思考原则：
- 首先识别事物的架构
- 追求事半功倍，解决一类事情而不是解决一件事情
- 融会贯通，用相同架构思维去解决不同领域的问题
我们需要站在高层次的维度，识别事物的本质，以全局和发展的视角去分析、解决问题。产出可执行落地的架构方案，并能有效解决一类问题。
二、PDSG架构深度解析
2.1 PDSG是什么
PDSG是描述架构的四个维度，任何一个架构都可以通过这四个维度完整刻画：
| 维度 | 含义 | 回答的问题 | 英文 |
|---|---|---|---|
| P - 层级关系 (Position) | 各组件之间的横向/纵向、包含/并列关系 | 事物由什么组成？各部分什么关系？ | Hierarchy |
| D - 流传方向 (Direction) | 信息或数据从一个组件流向另一个组件的关系和方向 | 信息往哪里流？谁影响谁？ | Flow Direction |
| S - 传递方式 (Style) | 定义流转的介质、时序、条件等信息 | 用什么方式传递？同步还是异步？ | Transfer Style |
| G - 差距/迁移 (Gap) | 当前架构与目标架构之间的差距 | 从现状到目标还差什么？ | Gap Analysis |
2.2 P - 层级关系：架构的骨架
层级关系描述了事物的静态结构，是架构的骨架。三个层次：
- 纵向：上下级包含关系（系统→子系统→模块→组件）
- 横向：同级并列关系（多个平行的子系统或模块）
- 边界：每个组件的职责边界和接口定义实战示例 — 医疗服务 系统 层级关系：
医疗服务系统
├── 业务系统（面向客户）
│ ├── 影像归档与传输系统
│ ├── 放射信息系统
│ ├── 影像平台
│ ├── 临床平台
│ ├── 核医学系统
│ ├── 超声内镜
│ └── 云影像平台
├── 交易系统（面向订单）
│ ├── 订单生成 → 订单完成
│ ├── 医院财务系统 / 运营平台财务系统
│ └── 财务结算
├── 业务支撑（面向商品）
│ ├── 功能树
│ ├── ITIL(DevOps)
│ └── 运维平台
└── 软件生产系统
├── 开发人员
├── 测试人员
└── 产品人员
关键洞察： 医院内生产系统的业务单据，本质上都是挂号单的子单（拍片单、检验单、住院单等）。识别出这种层级包含关系，就抓住了医疗服务系统的本质。
2.3 D - 流传方向：架构的血脉
流传方向描述了信息/数据/控制流的动态路径，是架构的血脉。核心要素：
- 方向：单向/双向/环形
- 触发条件：什么事件触发了流转
- 流转链路：经过了哪些节点实战示例 — 研发 系统 信息流转：
需求 → 需求澄清 → 方案评审 → 编码 → 功能测试 → 冒烟测试 → 性能测试 → 安全测试 → 版本输出
↑ ↓
└──── 工作回流 ←──────┘
关键洞察： 传统研发系统中存在大量"工作回流"（测试→研发→重新测试），导致流转效率极低。识别出回流节点，就是识别了系统瓶颈。
2.4 S - 传递方式：架构的神经
传递方式定义了信息流转的介质和协议，是架构的神经。核心维度：
| 维度 | 选项 | 影响 |
|---|---|---|
| 时序 | 同步/异步 | 响应速度 vs 吞吐量 |
| 介质 | API/消息队列/共享存储/文件 | 耦合度 vs 性能 |
| 条件 | 触发式/轮询式/事件驱动 | 实时性 vs 复杂度 |
| 批量 | 单条/批量/流式 | 延迟 vs 吞吐量 |
实战示例 — 研发 系统 传递方式优化：
| 原方式 | 优化方式 | 效果 |
|---|---|---|
| sprint周期同步输出（以月为单位） | 三集群异步输出（每天发版） | 交付周期从≥5个月缩短到天级 |
| 测试等环境（同步等待） | 交付集群多租户多版本共存 | 环境瓶颈消除 |
| 沟通回流（人工协调） | 功能树+常例会（结构化） | 减少系统调用回流 |
关键洞察： 高并发系统的三招——分流、缓存、异步，本质就是传递方式的优化。
2.5 G - 差距分析：架构的桥梁
差距分析连接了"当前架构"和"未来架构"，是架构迁移的桥梁。分析方法：
- 识别当前架构（PDSG-C）
- 识别未来架构（PDSG-F）
- 计算差集：Gap = PDSG-F - PDSG-C
- 产出迁移方案（5W3H）实战示例 — ITIL引入的差距分析：
| 维度 | 当前架构 | 未来架构 | 差距 |
|---|---|---|---|
| 层级(P) | 多产线多版本多SU异构，无统一管理框架 | ITIL体系下的标准化管理 | 缺少事故管理、变更管理、问题管理、资产管理、安全管理 |
| 流转(D) | 运维工单碎片化，无闭环 | ITIL标准流程闭环 | 流程不闭环 |
| 传递(S) | 线下/微信群沟通 | 飞书多维表格+ITIL工具链 | 无结构化管理 |
| 差距(G) | — | 引入ITIL + 功能树拓展补偿需求管理 | 权威体系引入 + 本地创新 |
三、五步法深度解析
3.1 五步法总览
五步法是架构思维的操作方法论，是从"识别问题"到"解决问题"的完整闭环：
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ 第1步 │ │ 第2步 │ │ 第3步 │ │ 第4步 │ │ 第5步 │
│ 识别 │ → │ 识别 │ → │ 分析 │ → │ 纠正与 │ → │ 项目 │
│ 当前架构 │ │ 未来架构 │ │ 架构差距 │ │ 补偿 │ │ 管理 │
└──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘
现状本质 目标性质 差集+迁移方案 未识别补偿 监督落地
铁律：不可以跳步！
3.2 第1步：识别当前架构
目标： 将事物现状的本质识别出来核心方法：
| 方法 | 描述 | 适用场景 |
|---|---|---|
| 经验类比 | 这件事跟另一件事差不多，另一件事是这样，所以这件事也是这样 | 有类似经验可参考时 |
| 本质推导（升维思考） | 将事物拆解到最基础的、本质上可以信赖的层次，从基础上往上推导 | 面对全新问题、无经验可参考时 |
本质推导的实战案例：
航天发射器是不是只能用一次就报废？为什么不能回收重复使用？回收不可实现？不回收的成本与回收的成本到底谁高？这种思维将问题回归到最基础的物理规律和经济规律，不被既有认知束缚。识别现状的难点：
| 难点 | 说明 | 应对策略 |
|---|---|---|
| 不可信 | 现有文档/描述碎片化、准确性低、时效性低 | 获得底层信息，亲自验证 |
| 隐性架构 | 流程/文化/利益格局未显式表达 | 多角色沟通，交叉验证 |
| 认知偏差 | 利益相关方对现状的描述不一致 | 事实驱动，数据说话 |
远程影像迁移案例中的精妙识别：
新部署影像云归档，考虑复用原有SaaS版互联网平台，涉及到集群、RocketMQ、RDS、Redis共用，打算在同一个机器的数据库中新建一个Database。研发评估需要3天验证"不同Database是否会串数据"。纠正与补偿： 不用担心串数据——因为绝对不允许运维在生产环境把两个不同的Database授权给同一个账号。通过账号来隔离数据，执行串数据的操作会报"数据库无法访问"异常，不会写入脏数据。3天验证→0天。识别当前架构的关键原则：
- 不要只看文档，要获得底层信息
- 不要只听一方，要多角色沟通
- 不要只看表面，要识别隐性架构（利益、文化、流程）
3.3 第2步：识别未来架构
目标： 将事物想要达成的目标性质识别出来核心约束：
- 未来架构必须是可达成的，不是幻想
- 未来架构必须是可验证的，有明确的成功标准
- 未来架构必须与第1步的现状识别对齐，不能脱节实战案例对照：
| 场景 | 当前架构 | 未来架构 |
|---|---|---|
| 归档系统报修积压 | Hotfix全量测试+回归主干，流程过长 | 拉分支hotfix，不用回归主线 |
| 影像平台客户自服务 | 未实现租户间数据隔离，运营权无法移交 | 前后端分离+后端多租户化 |
| A战区 | 碎片化信息，不可信 | 影像云归档采存管用拆分，运营功能完善 |
| B战区 | 运营功能交付慢，结算对账是痛点 | 运营中台+多版本多租户快迭代 |
识别未来架构的关键原则：
- 要区分"想要的"和"能做到的"，实事求是
- 要考虑约束条件（技术可行性、资源可用性、时间窗口）
- 要有明确的优先级——先解决什么，后解决什么
3.4 第3步：分析架构差距
目标： 得到差集，产出迁移方案（5W3H）方法论： 将第1步的PDSG-C与第2步的PDSG-F逐维度对比：
| 对比维度 | 方法 |
|---|---|
| P（层级） | 当前层级 vs 目标层级 → 缺少哪些组件？需要拆分/合并哪些？ |
| D（流转） | 当前流转 vs 目标流转 → 哪些路径需要新增？哪些需要删除？ |
| S（传递） | 当前方式 vs 目标方式 → 哪些同步需改异步？哪些人工需改自动化？ |
| G（差距） | 综合差距 → 按优先级排序，制定5W3H方案 |
5W3H迁移方案模板：
| 要素 | 问题 | 回答 |
|---|---|---|
| What | 做什么 | 迁移的具体内容和范围 |
| Why | 为什么做 | 差距分析中的哪个Gap |
| Where | 在哪里做 | 试点环境/生产环境 |
| When | 什么时候做 | 里程碑时间节点 |
| Who | 谁来做 | 责任人和团队 |
| How | 怎么做 | 迁移方法（全新安装/就地迁移/灰度迁移） |
| How much | 多少成本 | 人力、时间、资源 |
| How many | 多少量级 | 影响范围、迁移数量 |
实战案例 — 研发系统差距分析：
| 差距 | 当前 | 目标 | 迁移方案 |
|---|---|---|---|
| 交付周期≥5个月 | sprint月度同步输出 | 三集群异步输出 | 建立交付集群，每天发版 |
| 环境瓶颈 | 测试等环境 | 多租户多版本共存 | 技术底座：多租户数据隔离 |
| 沟通回流 | 人工协调 | 功能树+常例会 | 吐槽群+功能树+产能量化 |
3.5 第4步：纠正与补偿
目标： 在已经确定的1、2前提下，对未识别到的内容进行补偿，解决3中遇到的问题这是五步法中最考验功力的一步。 它要求：
- 扎实的技术水平：知晓技术上的各种可能性
- 应急处理能力：冷静分析，得到最合理的解决方案
- 不轻易推翻原有架构设计：融会贯通，而非推倒重来纠正与补偿的典型场景：
| 场景 | 问题 | 补偿方案 |
|---|---|---|
| 远程影像迁移 | 担心不同Database串数据 | 账号隔离，不需要3天验证 |
| 归档系统 | hotfix不全量回归容易功能退化 | 增加白盒审核 |
| 影像平台 | 放射信息系统后端.net多租户化困难 | 放射信息系统后端低代码改造 |
| 影像平台 | 放射信息系统前端代码可维护性差 | 借本次改造扩大重构范围 |
| A战区 | 有潜在在谈客户怎么办 | 暂停功能迭代≠产品退市，谈判识别真实收入 |
| A战区 | 临时插入安全护网、信创演示 | 约定外的关键事件，动态调整 |
纠正与补偿的三个层次：
- 技术补偿：用技术手段解决未预见到的问题（如白盒审核替代全量回归）
- 流程补偿：用流程机制弥补技术方案的不足（如固定时间集中变更评审）
- 组织补偿：用组织手段解决跨团队协调问题（如架构委员会review方案）
3.6 第5步：项目管理
目标： 监督执行方案的落地核心原则： 五步法的每一步都不是一次性的，项目管理贯穿始终，确保方案真正落地。项目管理的架构思维：
| 维度 | 方法 |
|---|---|
| 节点协调 | 不同战区/产线的里程碑节点错开 |
| 削峰填谷 | 产线化+产能化，动态调配资源 |
| 以战养兵 | 一边防御一边练兵，越战越强 |
| 及时止损 | 方向错误时果断调整 |
| 信息同步 | 保持与客户/团队的信息同步频次 |
实战案例 — A战区项目管理：
- 审核变更单，群里勾兑状态同步
- 架构委员会review方案
- 影像云归档"采存管用"拆分，增切减平滑过渡
- 数据跟踪、对账实战案例 — B战区项目管理：
- 低代码改造与A战区影像云归档改造错峰
- 域名申请与客户协调时间
- 保持与客户的信息同步和沟通频次
四、PDSG × 五步法的交叉应用
4.1 PDSG与五步法的关系
PDSG是描述工具（what），五步法是操作方法（how），两者交叉形成完整的架构思维框架：
| 五步法步骤 | P维（层级） | D维（流转） | S维（传递） | G维（差距） |
|---|---|---|---|---|
| 1.识别当前 | 当前层级结构 | 当前信息流 | 当前传递方式 | — |
| 2.识别未来 | 目标层级结构 | 目标信息流 | 目标传递方式 | — |
| 3.分析差距 | 层级差集 | 流转差集 | 传递差集 | 综合差距 |
| 4.纠正补偿 | 组织/结构调整 | 流程补偿 | 技术/工具补偿 | 风险补偿 |
| 5.项目管理 | 资源调配 | 节点协调 | 沟通机制 | 变更管理 |
4.2 完整案例推演：研发系统优化
第1步：识别当前架构（PDSG-C）
- P（层级） ：需求→研发→测试→发布，串行pipeline
- D（流转） ：需求月度同步流转，版本周期≥5个月
- S（传递） ：sprint同步输出，测试等环境（同步阻塞），沟通回流
- 识别出三大瓶颈：单点瓶颈、性能撑满、需要快速通道第2步：识别未来架构（PDSG-F）
- P（层级） ：三交付集群并行，商品池统一管理
- D（流转） ：需求每天流转，交付周期从月级到天级
- S（传递） ：三集群异步输出，多租户多版本共存第3步：分析架构差距
- 分流：足够多的环境，多租户多版本共存
- 缓存：减少沟通回流，功能树+常例会
- 异步：版本输出从sprint周期到三集群异步输出第4步：纠正与补偿
- 吐槽群：快速响应需求的补偿机制
- 交付前置：在交付集群完成功能测试、安全测试、白盒review
- 产品试用：用产能量化替代主观评估第5步：项目管理
- 每天发版打分通过进入商品池
- 功能树量化产能
- 削峰填谷，产线化产能化
五、三大难点与突破
5.1 识别现状的难点
| 难点 | 表现 | 突破方法 |
|---|---|---|
| 信息不可信 | 文档碎片化、准确性低、时效性低 | 获得底层信息，亲自验证 |
| 隐性架构未显式表达 | 利益格局、文化惯性、潜规则 | 多角色沟通，交叉验证 |
| 客户调研陷阱 | 客户对A/B的认识 ≠ 乙方对A/C的认识 | 区分甲方决策逻辑和乙方决策逻辑 |
5.2 迁移逻辑不等式
客户迁移决策的核心公式：
新体验 - 旧体验 > 替换成本（采购费用 + 习惯迁移时间成本）
乙方决策逻辑：
产品研发投入 < 客户数 × 边际利润（售价 - 边际服务成本）
关键洞察： 不要只从乙方视角看问题，要从甲方迁移逻辑不等式出发，确保产品价值 > 迁移成本。
5.3 程序正义与结果正义
| 概念 | 含义 | 关系 |
|---|---|---|
| 程序正义 | 基于现状分析，以最合理、最高效的步骤向目标推进 | 提供支撑 |
| 结果正义 | 在当下环境及步骤下，实际获得的进展即为最权威的结果 | 促进完善 |
两者不是对立的，而是互补的。程序正义提供方向和方法，结果正义验证和校正。
六、液态组织：架构思维的终极形态
6.1 液态组织的定义
强调员工灵活性和自主性，工作中更依赖于员工之间的协作和互相支持，鼓励员工创新和自主性，并提供了更多的自由度，以便员工更好地适应快速变化的市场环境。
6.2 液态组织的基础
产线化 + 产能化：
| 基础 | 含义 | 作用 |
|---|---|---|
| 产线化 | 将资源池划分为不同产线，研发聚焦相应层面，产线负责人统一管理 | 动态规划的基础 |
| 产能化 | 通过产线人数、产能标准、功能树梳理，量化单位时间内交付能力 | 支撑快速准确的评估和预测 |
| 系统与流程 | 通过景观图梳理工作/业务流程的各环节，互相的联系与执行内容 | 拉齐认知，建立相同沟通语境 |
6.3 液态组织的流动方式
| 流动维度 | 方式 | 触发条件 |
|---|---|---|
| 产线内流动 | 不同角色（产品/研发/测试）调整到合适比例 | 产线需求变化 |
| 产线间流动 | 产线稳态迭代或能力补齐时调动 | 产能匹配需求 |
| 战区间流动 | 根据客户诉求及项目难易度调度 | 战区优先级变化 |
| 职能间流动 | 产品/研发/测试角色调整 | 节点瓶颈 |
6.4 液态组织的三大好处
- 削峰填谷：根据实际情况快速响应，实时调度，达到资源均衡
- 选拔人才：每个人需要熟悉框架流程，优秀成员被看见和认可
- 能者多得：能力强者多处补位，多劳者得到更多激励
七、速查卡片
五步法速查
| 步骤 | 目标 | 核心方法 | 铁律 |
|---|---|---|---|
| 1.识别当前架构 | 现状本质 | 经验类比 + 本质推导（升维思考） | 不可跳步 |
| 2.识别未来架构 | 目标性质 | 约束条件下的可达目标 | 不脱离现状 |
| 3.分析架构差距 | 差集+迁移方案 | PDSG逐维度对比 + 5W3H | 不遗漏维度 |
| 4.纠正与补偿 | 未识别补偿 | 技术+流程+组织三层补偿 | 不轻易推翻 |
| 5.项目管理 | 监督落地 | 削峰填谷+以战养兵+及时止损 | 贯穿始终 |
PDSG速查
| 维度 | 问题 | 关键词 |
|---|---|---|
| P 层级关系 | 事物由什么组成？ | 结构、组件、包含、并列 |
| D 流传方向 | 信息往哪里流？ | 方向、链路、触发条件 |
| S 传递方式 | 用什么方式传递？ | 同步/异步、介质、时序 |
| G 差距分析 | 现状到目标差什么？ | 差集、迁移方案、5W3H |
