Appearance
TOGAF 深度实践：从订单重构到企业级变革
一家拥有 1200 家门店、商城和小程序的零售企业决定建设“统一订单中心”。后端团队用了领域驱动设计，按订单、库存、支付和履约拆分服务，引入消息队列、分布式追踪和容器平台。单看技术方案，它具备一套现代系统应有的结构。
半年后，问题并没有消失：门店和商城仍使用不同的商品编码；商城认为“已下单未支付”需要锁定库存，门店却在付款后才扣减；会员等级由三个系统分别维护；旧 POS 无法一次替换，新订单中心只能同时兼容新旧两套状态；业务团队为了赶活动，又在营销系统里复制了一套库存判断。
这个项目缺的不是更好的服务拆分，而是对企业变化的整体设计。系统架构回答“订单中心怎么构建”，企业架构还要回答另外一组问题：为什么先改订单而不是会员或库存，哪些业务能力需要变化，核心事实由谁负责，旧系统如何退出，多个项目如何按依赖关系推进，以及局部项目偏离目标时如何纠正。
TOGAF 的价值就在这里。它不是帮助架构师多画几张图，而是把一次跨组织、跨系统、跨年度的变化，组织成一条可解释、可实施、可验证的决策链。
专题切入点
这篇主文先把整条决策链串起来，具体问题可以继续进入对应专题：
| 切入问题 | 深入页面 |
|---|---|
| 同一套方法怎样进入营销决策、权益和归因 | 营销系统架构实战 |
| 按核心问题校准概念边界和应用判断 | 核心问题与应用辨析 |
| 谁的关注点决定范围，原则如何进入项目 | 干系人与架构原则 |
| 架构工作怎样从授权走到反馈 | ADM 方法 |
| 战略结果怎样拆成能力和责任 | 业务架构 |
| 核心事实怎样定义权威和生命周期 | 数据架构 |
| 应用边界怎样从能力与事实推导 | 应用架构 |
| 质量属性怎样落成技术与运行机制 | 技术架构 |
| 决策怎样成为可复用、可追踪的资产 | 架构内容与仓库 |
| 现状和目标怎样形成可执行 Gap | Baseline、Target 与 Gap |
| 企业不停机时怎样设计过渡与迁移 | 过渡架构与迁移规划 |
| 目标怎样进入交付并控制偏差 | 架构治理 |
企业架构与系统架构的边界
资深后端工程师通常已经熟悉模块划分、数据一致性、性能、可靠性和可观测性。这些能力依然重要，但它们主要工作在一个确定的系统边界内。企业架构处理的是边界尚未确定时的上游问题。
| 维度 | 系统或解决方案架构 | 企业架构 |
|---|---|---|
| 核心对象 | 一个系统、产品或项目 | 业务能力、数据、应用组合、技术平台与组织变革 |
| 典型问题 | 服务怎么拆、接口怎么定、故障怎么隔离 | 为什么改变、改变哪些能力、由哪些项目按什么顺序完成 |
| 时间跨度 | 一个版本到数个季度 | 多个项目、多个预算周期 |
| 约束来源 | 功能、性能、安全、交付计划 | 战略、组织职责、法规、既有资产、投资组合和技术约束 |
| 成功标准 | 系统按质量要求交付并稳定运行 | 企业达到目标能力，旧状态退出，收益持续兑现 |
| 主要风险 | 设计错误或实现失效 | 每个项目都局部合理，但组合起来没有到达共同目标 |
企业架构不会替代领域驱动设计、微服务或技术方案设计。它决定这些方法应该解决哪一段问题，并确保不同团队的局部设计共同指向一个目标状态。
案例边界与已知约束
后续推演使用同一个虚构案例。数字只是为了让判断具备工程尺度，不代表某家真实企业。
企业希望在十二个月内实现全渠道交易和履约，业务目标包括：会员跨渠道识别、订单统一查询、线上下单门店自提、库存可售口径统一，以及售后处理状态可追踪。当前系统包括门店 POS、商城、会员系统、仓储 WMS、财务系统和多套区域接口。
已知约束如下：
- POS 由不同供应商维护，十二个月内无法全部替换。
- WMS 只能稳定提供批量库存和出入库接口，暂时不能承接高频实时查询。
- 大促峰值下单请求预计为每秒 2500 次，商品浏览远高于下单流量。
- 订单和支付记录需要满足审计与财务对账要求，迁移过程不能丢失历史状态。
- 门店运营不能接受长时间停机，系统切换必须按区域和门店分批进行。
- 会员、商品、库存和订单目前没有统一的数据 Owner。
这些约束很重要。没有约束的目标架构只是愿望；企业架构工作的起点，是承认企业不能停下来重新建设。
建立可追踪的架构问题
“建设统一订单中心”不是一个合格的架构问题，因为它已经预设了解法。架构工作首先需要把方案语言还原成业务驱动、预期结果和约束。
| 编号 | 类型 | 内容 | 验证方式 |
|---|---|---|---|
| DRV-01 | 业务驱动 | 全渠道销售要求客户在任意渠道查询和处理订单 | 跨渠道订单可见率 |
| DRV-02 | 业务驱动 | 库存不一致造成超卖、缺货取消和人工协调 | 超卖率、缺货取消率、人工调账量 |
| DRV-03 | 运营驱动 | 新渠道接入需要重复对接会员、商品、库存和订单 | 新渠道接入周期 |
| CON-01 | 约束 | POS 和 WMS 不能在本轮全部替换 | 过渡期兼容范围 |
| CON-02 | 约束 | 核心交易需要完整审计与对账 | 审计链完整率、账实差异量 |
这里已经发生了第一次关键转变：架构目标不再是“上线一个订单中心”，而是降低超卖和重复建设，使全渠道订单可见，并在不能停机重建的条件下完成责任迁移。订单中心只是可能的解法之一。
从战略结果推导业务能力
业务架构最容易被误写成组织结构图或流程图。更有效的起点是区分目标、能力、流程和系统：
- 目标描述希望获得的业务结果，例如降低缺货取消率。
- 业务能力描述企业必须具备什么，例如全局库存可视和库存承诺。
- 流程描述不同角色如何完成一次工作，例如门店自提履约。
- 系统是当前承载能力的工具，不等于能力本身。
能力比流程和系统更稳定。门店自提流程可以调整，POS 可以替换，但“库存承诺”和“订单履约”仍然存在。这种稳定性使能力地图适合连接战略和投资组合。
能力热力分析
| 业务能力 | 当前状态 | 目标状态 | 影响 | 判断 |
|---|---|---|---|---|
| 会员识别 | 各渠道维护局部身份 | 统一客户标识并保留渠道身份映射 | 权益、营销、售后 | 优先补齐 |
| 商品管理 | 商品编码和类目不统一 | 建立企业商品标识和渠道映射 | 交易、库存、分析 | 基础依赖 |
| 库存可视 | 门店、仓库和商城分别计算 | 形成可解释的全局库存视图 | 超卖、履约承诺 | 核心差距 |
| 库存承诺 | 渠道各自锁定或扣减 | 统一预占、释放和确认规则 | 下单成功率 | 核心差距 |
| 订单管理 | 订单状态和编号分散 | 统一订单身份与状态语义 | 查询、售后、财务 | 核心差距 |
| 履约编排 | 人工选择仓库或门店 | 按库存、时效和成本选择节点 | 履约成本、体验 | 后续增强 |
能力热力分析改变了项目顺序。如果商品身份和库存语义没有统一，先建设订单中心只会迫使它兼容更多歧义。合理的路线可能先建立商品映射和库存视图，再迁移库存承诺责任，最后逐步接管订单状态。
用价值流检查能力是否完整
能力地图回答企业“能做什么”，价值流检查客户价值如何穿过这些能力。以“客户购买并收到商品”为例，价值流可以划分为识别客户、选择商品、确认价格、承诺库存、创建交易、完成支付、安排履约、交付和售后。
如果“承诺库存”没有明确能力和负责人，它就会散落在商城、POS、WMS 和人工规则中。价值流中的断点，往往比系统清单更早暴露企业架构问题。
数据架构先确定事实责任
数据库表属于哪个服务，是应用设计问题；企业中的核心事实由谁定义、谁有权改变、其他系统如何使用，是数据架构问题。
库存尤其容易暴露语义冲突。“库存数量”至少可能包含：
- 实物库存：某地点实际持有的数量。
- 质检或冻结库存：存在但暂时不能销售的数量。
- 安全库存：为了不确定性而保留的缓冲量。
- 锁定库存：已被订单占用但交易尚未最终确认的数量。
- 可售库存：在特定渠道、地点和时间上允许承诺给客户的数量。
- 在途库存：已经发出但尚未进入目标地点的数量。
在简化模型中，可售库存可以表达为：
text
可售库存 = 实物库存 - 冻结库存 - 安全库存 - 已锁定库存真实企业还会叠加渠道配额、预售规则、履约范围、时效和优先级。因此，可售库存不是一个可以被所有系统随意修改的字段，而是有业务规则、输入事实和时间语义的计算结果。
核心数据责任矩阵
| 数据对象 | 业务定义负责人 | 权威写入方 | 主要消费者 | 关键规则 |
|---|---|---|---|---|
| 客户身份 | 会员运营 | 会员中心 | 渠道、订单、客服 | 企业客户 ID 唯一，渠道 ID 可多值映射 |
| 商品身份 | 商品运营 | 商品中心 | 渠道、库存、订单、分析 | 企业 SKU 与渠道 SKU 分离 |
| 实物库存 | 仓储与门店运营 | WMS、POS 库存台账 | 库存平台、财务 | 每次变更保留来源、地点和业务凭证 |
| 库存锁定 | 交易运营 | 库存承诺服务 | 订单、渠道、履约 | 锁定有期限，释放必须幂等 |
| 订单状态 | 交易运营 | 订单管理 | 渠道、客服、财务、履约 | 状态变化有前置条件和审计轨迹 |
| 履约状态 | 履约运营 | 履约系统 | 订单、客服、客户通知 | 包裹与订单不是一对一关系 |
“权威写入方”并不要求所有数据都存进同一个数据库。它要求同一个业务事实只有一个最终裁决者。消费者可以建立本地读模型，但不能绕过权威方改变事实。
先处理身份，再处理同步
如果同一件商品在 POS 中是 A-1024，在商城中是 SKU-8848，在 WMS 中又按箱规编码，增加 Kafka 并不能解决问题。消息传播得越快，只会越快地复制歧义。数据架构需要先建立企业标识、来源标识映射、语义标准、状态生命周期和数据质量规则，之后才讨论 API、事件或批处理。
每个核心对象至少应记录以下内容：
| 项目 | 需要回答的问题 |
|---|---|
| 语义 | 这个对象代表什么，不代表什么 |
| 身份 | 如何唯一识别，如何关联旧系统标识 |
| 生命周期 | 谁可以创建、变更、失效和恢复 |
| 责任 | 业务 Owner、数据 Steward 和技术维护方是谁 |
| 时效 | 多久更新一次，消费者能容忍多旧的数据 |
| 质量 | 完整性、唯一性、一致性如何度量 |
| 安全 | 哪些字段敏感，谁能读取和修改 |
| 血缘 | 数据从哪里产生，经过哪些转换，到哪里被使用 |
从能力与事实推导应用边界
应用架构不是给现有系统重新画框。系统边界应该同时考虑业务能力内聚、数据责任、事务一致性、变化节奏、团队职责和故障隔离。
以库存为例，如果把“查询库存”放到商品服务、“锁定库存”放到订单服务、“释放库存”放到定时任务、“库存调整”留在 WMS，那么库存规则仍然没有主人。服务数量增加了，责任却更分散。
更合理的目标责任可以是：
| 应用能力 | 负责内容 | 明确不负责 |
|---|---|---|
| 渠道应用 | 展示、交互、渠道特有编排 | 定义企业商品、会员和库存事实 |
| 会员中心 | 客户身份、等级、权益账户 | 订单流转和库存判断 |
| 商品中心 | 企业商品、类目和渠道映射 | 渠道页面和库存数量 |
| 订单管理 | 订单生命周期、价格快照、支付关联 | 直接修改实物库存和履约节点库存 |
| 库存平台 | 库存视图、预占、释放、确认和调整记录 | 决定订单是否有效、处理支付 |
| 履约系统 | 拆包裹、选节点、发货、签收和异常履约 | 修改订单交易规则 |
同步调用与事件传播承担不同责任
下单链路中，需要立即告诉客户结果的校验通常走同步调用；一个事实发生后通知多个系统，通常使用事件。两者不能仅按“性能高低”选择。
text
客户端 -> 订单管理：提交订单
订单管理 -> 库存平台：请求预占，等待明确结果
订单管理 -> 支付平台：创建支付意图
订单管理：订单进入待支付状态
订单管理 -> 事件总线：发布“订单已创建”
支付平台 -> 订单管理：支付结果回调
订单管理：校验状态并记录支付事实
订单管理 -> 事件总线：发布“订单已支付”
库存平台 <- 订单已支付：把预占转为确认扣减
履约系统 <- 订单已支付：开始履约规划同步调用必须设计超时、幂等和失败语义。事件必须设计唯一标识、版本、顺序要求、重复消费、重试、死信和补偿。事件名应该描述已经发生的业务事实，例如“订单已支付”，而不是把“扣减库存”伪装成事件。后者实际上是跨系统命令，会隐藏责任关系。
架构决策需要保留被放弃的选项
“使用微服务”不是充分的决策记录。架构决策至少要说明问题、约束、候选方案、选择理由、负面后果和复审条件。
例如库存平台第一阶段可以选择模块化单体，而不是立即拆成多个服务：库存语义和团队责任仍在快速变化，强行分布式拆分会增加一致性和运维成本。等预占、调整、视图和规则引擎出现独立扩缩容或团队边界后，再拆部署单元。企业架构确定责任边界，不要求责任边界立即等于微服务边界。
技术架构从业务损失推导质量属性
技术架构常被写成 Redis、Kafka、Kubernetes 和数据库产品列表。真正需要设计的是质量属性场景：谁在什么条件下发起什么操作，系统应在多长时间内给出什么结果，失败时允许损失多少业务。
| 业务场景 | 可量化要求 | 技术含义 | 验证方式 |
|---|---|---|---|
| 大促创建订单 | 峰值 2500 次/秒，99.9% 请求在目标时延内完成 | 无状态扩展、热点隔离、容量余量、入口保护 | 分层压测与容量模型 |
| 库存预占 | 同一库存单元不能超额承诺 | 单一写入责任、原子条件更新或串行化、幂等 | 并发冲突测试、账实核对 |
| 支付回调 | 重复、乱序和延迟到达不能重复入账 | 幂等键、状态机约束、持久化事件 | 故障注入和重放测试 |
| 订单查询 | 单个依赖故障不应使全部历史订单不可查 | 读模型、缓存、降级、隔离 | 依赖中断演练 |
| 核心数据恢复 | 明确 RPO、RTO 和恢复顺序 | 备份、日志归档、跨故障域部署、恢复手册 | 定期恢复演练 |
业务目标不能直接等于系统指标。“订单创建接口 99.99% 可用”仍然不足以证明客户能完成交易。支付、库存、订单状态和履约事件组合起来才是业务成功率。因此技术观测需要同时保留技术指标和业务状态指标。
容量模型保留假设
如果活动预计每秒产生 2500 次下单请求，不能把所有服务统一按 2500 QPS 扩容。需要继续拆解：
- 一次下单包含多少商品行，会产生多少次库存预占。
- 商品详情和库存展示流量是下单流量的多少倍。
- 支付回调的峰值是否滞后于下单峰值。
- 一个订单可能拆成多少履约单和包裹。
- 消息系统短时不可用时，本地待发送记录会增长多快。
- 数据库主从延迟、缓存过期和队列积压分别允许持续多久。
容量结论应当能追溯到这些假设。压测不是为了证明系统“扛得住”，而是验证模型、找到拐点并明确降级顺序。
观测业务事实而不只观测组件
CPU、堆内存和接口时延只能说明组件是否健康。交易链路还需要回答：有多少订单长时间停留在待支付，有多少已支付订单没有确认库存，有多少库存锁定超过期限，有多少履约单没有进入可执行状态。
可以围绕业务主键建立追踪：
text
customer_id -> cart_id -> order_id -> payment_id
-> reservation_id -> fulfillment_id -> package_id这些关联使运维人员能够从客户投诉回到业务状态，再定位到事件、日志、数据库记录和具体服务，而不是在几十个仪表盘之间猜测。
Baseline、Target 和 Gap 是一套推理模型
Baseline 不是服务器和系统清单，Target 也不是一张未来蓝图。二者必须使用可比较的维度描述，否则 Gap 只能写成“建设新平台”这样的项目口号。
| 维度 | Baseline | Target | Gap |
|---|---|---|---|
| 业务能力 | 渠道独立承诺库存 | 企业级库存承诺 | 统一规则、责任和异常流程 |
| 数据 | 多套商品与库存标识 | 企业标识及来源映射 | 清洗、映射、质量度量和 Owner |
| 应用 | 商城和 POS 各自锁定库存 | 库存平台成为预占权威方 | 接口改造、状态迁移、旧逻辑退出 |
| 技术 | 批量同步，无法支撑实时承诺 | 实时预占并保留批量对账 | 事件链路、幂等、补偿、观测和容量 |
| 组织 | 多团队共同修改库存规则 | 明确产品 Owner 和值班责任 | 职责调整、治理流程和运行手册 |
一个可执行 Gap 不只描述缺什么，还应记录证据、依赖、负责人、完成条件和风险。
yaml
id: GAP-INV-03
problem: 商城与门店分别维护库存锁定，存在重复承诺
target: 库存平台成为线上渠道库存预占的唯一写入方
depends_on:
- DATA-SKU-MAPPING
- CAP-INVENTORY-COMMITMENT
owner: 交易与库存联合团队
exit_criteria:
- 新渠道预占请求 100% 进入库存平台
- 连续四周不存在旧链路新增锁定记录
- 超时释放和支付确认均通过故障注入测试
evidence:
- 调用链流量报表
- 数据对账报告
- 故障演练记录有了这种粒度，Gap 才能进入投资排序、项目规划和治理。否则，架构工作会在目标图完成后与交付脱节。
过渡架构决定目标能否到达
目标状态往往很整洁：统一会员、统一商品、统一库存、统一订单。真正困难的是旧系统仍在运行时，某个事实到底由谁负责。
库存责任可以分阶段迁移：
| 阶段 | 新平台责任 | 旧系统责任 | 切换证据 |
|---|---|---|---|
| T0 基线 | 汇总数据但不参与交易 | 各渠道继续判断和扣减 | 建立跨系统库存差异基线 |
| T1 影子计算 | 实时计算可售库存并与旧结果比较 | 仍是交易权威方 | 差异原因可分类，规则逐步收敛 |
| T2 局部接管 | 对一个渠道或区域提供预占和释放 | 未迁移渠道仍由旧系统负责 | 单一范围内只有一个写入权威方 |
| T3 扩大接管 | 覆盖线上和支持改造的门店 | 只保留适配和本地容错 | 旧锁定逻辑无新增数据 |
| T4 目标状态 | 统一承诺、观测和审计 | 旧逻辑下线，保留必要查询 | 依赖、任务和写入口全部清退 |
双写不是迁移目标
双写有时用于短期过渡，但它制造了“两个写入都可能成功或失败”的状态空间。如果无法定义失败补偿、对账频率、冲突裁决方和退出时间，双写会从临时方案变成永久架构。
更稳妥的原则是：任何一个迁移范围和时间窗口内，都尽量只有一个权威写入方。其他系统通过事件、变更数据捕获、反腐层或读模型获取状态。必须双写时，把它登记为有到期日的架构例外。
迁移要覆盖历史、增量和回退
数据迁移不只是执行一次 SQL。至少需要设计：
- 历史数据如何清洗、映射和校验。
- 迁移期间新增和修改的数据如何追平。
- 切换点如何冻结或协调写入。
- 新旧结果如何按业务主键对账。
- 出现严重偏差时回退代码、流量和数据的顺序。
- 回退后新系统已经产生的数据如何处理。
这些内容共同构成过渡架构，而不是项目上线前临时补充的运维步骤。
从 Gap 形成工作包和迁移路线
工作包不应直接等同于“开发一个微服务”。它应组合一组能够产生可验证业务结果的差距，并包含业务、数据、应用、技术和组织变化。
| 工作包 | 包含内容 | 前置依赖 | 业务结果 |
|---|---|---|---|
| WP1 身份与语义基础 | 商品映射、客户标识、数据 Owner、质量规则 | 无 | 跨系统数据可以准确关联 |
| WP2 库存可视 | 汇总实物、锁定和冻结库存，建立差异分析 | WP1 | 运营能解释库存差异 |
| WP3 库存承诺 | 预占、释放、确认、幂等和异常补偿 | WP1、WP2 | 新渠道不再各自实现锁定规则 |
| WP4 订单状态统一 | 企业订单 ID、状态模型、历史查询和审计 | WP1、WP3 | 客户和客服跨渠道查单 |
| WP5 履约编排 | 选节点、拆包裹、门店自提和异常处理 | WP2、WP4 | 提升履约成功率和可追踪性 |
| WP6 遗留退出 | 流量清退、任务停用、接口下线、数据归档 | 前述工作包 | 降低双轨维护成本和架构债务 |
路线图不是甘特图的替代品。它表达能力增量、过渡架构、项目依赖、收益节点和风险。详细任务仍然由项目计划和交付团队管理。
优先级可以综合业务价值、风险降低、时间紧迫性、依赖关系和实施规模。具体使用哪种评分方法并不重要，重要的是保留假设，避免“领导最关注”或“技术团队最想重构”成为唯一排序依据。
架构治理要进入交付和运行过程
如果架构治理只发生在项目立项评审，后续每一次需求变更和交付压力都会侵蚀目标架构。治理需要把架构约束转成持续可检查的证据。
| 阶段 | 治理对象 | 可检查证据 |
|---|---|---|
| 方案阶段 | 原则、边界、数据责任和质量属性 | 架构决策记录、数据责任矩阵、威胁模型 |
| 开发阶段 | 接口契约、事件兼容、安全和依赖方向 | 契约测试、Schema 兼容检查、静态规则 |
| 发布阶段 | 容量、回退、迁移和运行准备 | 压测报告、恢复演练、迁移对账、运行手册 |
| 运行阶段 | SLO、业务状态、数据质量和成本 | 仪表盘、错误预算、质量报告、成本分摊 |
| 退出阶段 | 旧入口、旧数据和旧责任是否清退 | 流量证明、任务清单、归档和下线记录 |
例外管理保护长期方向
业务团队为了赶活动，可能暂时无法接入统一库存平台。治理不应只回答“允许”或“不允许”，而要记录：
- 为什么现有能力不能满足需求。
- 临时方案会破坏哪些原则和目标。
- 如何隔离影响并补齐观测、审计和对账。
- 谁承担风险。
- 例外何时到期，退出条件是什么。
没有到期日和退出条件的例外，就是未经承认的新架构。
把 ADM 理解为控制回路
ADM 的阶段名称容易给人瀑布流程的印象。实际应用中，它更像围绕需求和证据不断收敛的控制回路。
| ADM 阶段 | 在案例中的实际问题 |
|---|---|
| Preliminary | 是否具备架构角色、原则、资产库和决策机制 |
| Phase A 架构愿景 | 为什么改变、范围多大、关键干系人是否承诺 |
| Phase B 业务架构 | 哪些能力和价值流必须改变 |
| Phase C 数据与应用架构 | 核心事实由谁负责，应用责任如何重划 |
| Phase D 技术架构 | 质量属性需要哪些平台能力和技术机制 |
| Phase E 机会与解决方案 | Gap 如何组合成工作包和过渡架构 |
| Phase F 迁移规划 | 依赖、收益、风险和资源如何决定顺序 |
| Phase G 实施治理 | 项目是否遵循目标和过渡架构 |
| Phase H 变更管理 | 新业务、运行证据和外部变化是否要求调整架构 |
需求管理贯穿全程，不是维护一张不断增长的需求表，而是让业务驱动、架构要求、项目交付和运行证据可以相互追踪。发现库存预占时延不达标，既可能调整技术方案，也可能暴露业务规则、数据语义或容量假设错误。反馈可以返回任一架构域，而不是等下一轮“大规划”。
一次完整 ADM 可以覆盖企业级规划，也可以围绕一个能力增量迭代。裁剪的依据是风险、范围和组织成熟度，不是机械地删掉文档名称。
TOGAF 与后端工程方法的关系
TOGAF、DDD、微服务、平台工程和 DevOps 解决的问题层次不同。把它们串起来，才能避免在错误的问题上使用正确的技术。
| 方法 | 主要回答的问题 | 在案例中的作用 |
|---|---|---|
| TOGAF | 为什么变化、改变哪些能力和资产、如何迁移与治理 | 决定库存承诺是关键能力，安排责任迁移和工作包 |
| DDD | 业务语言、规则和模型边界如何表达 | 区分订单、库存、支付和履约上下文 |
| 微服务 | 哪些能力需要独立开发、部署、扩缩容和隔离 | 在边界稳定且收益明确时拆部署单元 |
| 事件驱动 | 跨边界事实如何传播并解耦时间依赖 | 传播订单已支付、库存已确认等事实 |
| 平台工程 | 团队如何低成本获得可靠的通用能力 | 提供部署、观测、消息、安全和数据基础设施 |
| DevOps/SRE | 设计如何通过交付和运行反馈持续验证 | 用 SLO、错误预算、演练和业务指标验证架构 |
TOGAF 不会直接推导出应该有多少个微服务。它先明确能力、责任、约束和目标。DDD 帮助发现模型边界，解决方案架构评估一致性、部署和团队条件，之后才决定采用模块化单体还是微服务。
建立端到端追踪链
架构是否真正可执行，可以检查一条业务驱动能否追踪到运行证据。
| 层级 | 编号 | 决策或产物 |
|---|---|---|
| 业务驱动 | DRV-02 | 降低库存不一致导致的超卖和取消 |
| 业务结果 | OUT-INV-01 | 缺货取消率下降，人工调账量降低 |
| 业务能力 | CAP-INV-COMMIT | 统一库存承诺 |
| 数据责任 | DATA-RESERVATION | 库存平台拥有锁定、释放和确认事实 |
| 应用责任 | APP-INVENTORY | 库存平台提供预占接口并发布库存事件 |
| 质量属性 | NFR-INV-01 | 高并发下同一库存单元不得超额承诺 |
| Gap | GAP-INV-03 | 清退商城和 POS 的局部锁定逻辑 |
| 工作包 | WP3 | 库存承诺能力建设与渠道迁移 |
| 过渡架构 | TA-INV-02 | 选定渠道由新平台单一写入，其他渠道保持旧权威 |
| 运行证据 | EVD-INV-01 | 超卖率、锁定超时量、对账差异和旧入口流量 |
如果某个微服务、数据库或中间件无法回到这条链上的某个需求或约束，它可能只是技术偏好。如果某个业务目标没有对应的能力、Gap、工作包和度量，它仍然只是口号。
一套可交付的架构包
企业架构不要求每次生成厚重文档，但应保留支撑决策和迁移的最小证据。针对这个案例，一套可用的架构包包括：
- 架构工作范围、干系人关注点和关键约束。
- 可执行的架构原则及其衡量方式。
- 业务能力地图、热力分析和关键价值流。
- 核心数据对象、身份、生命周期和责任矩阵。
- 应用责任、交互契约和被放弃方案的决策记录。
- 质量属性场景、容量假设、安全边界和恢复目标。
- 可比较的 Baseline、Target 与 Gap 清单。
- 过渡架构、数据迁移、流量切换和回退方案。
- 工作包依赖、收益节点、风险和迁移路线图。
- 架构一致性证据、例外记录、运行指标和遗留退出清单。
工件的数量应当按决策风险裁剪。高风险库存迁移需要细化状态、对账和回退；低风险报表改造可能只需轻量决策记录。裁剪不是不做推理，而是只保留足以支撑协作和追责的表达。
能力验证
掌握 TOGAF 不以记住 ADM 阶段为标准，而以能否独立完成以下工作为标准：
- 把“建设某某平台”的方案要求还原为业务驱动、结果和约束。
- 区分业务能力、流程、数据对象、应用和技术组件，不把现有系统当成业务边界。
- 从核心事实的修改权推导应用责任，并识别共享数据库和重复写入背后的治理问题。
- 用业务损失和运行场景定义质量属性，而不是直接罗列技术产品。
- 用同一组维度描述 Baseline 和 Target，形成带负责人、依赖和退出条件的 Gap。
- 为不能停机重建的系统设计过渡架构，明确每个阶段的写入权威方。
- 把 Gap 组合成能够产生业务结果的工作包，而不是把服务开发清单当成路线图。
- 把架构约束转成契约测试、数据质量、SLO、演练和下线证据。
- 在业务、数据、应用、技术和迁移计划之间建立端到端追踪关系。
总结
TOGAF 的核心不是四个架构域，也不是按顺序完成一套模板。它提供的是企业变化的组织方式：从业务驱动出发，识别必须改变的能力和事实责任，形成应用与技术决策，比较现状和目标，把差距组合成过渡架构与工作包，再用交付和运行证据持续校正。
后端架构关注代码、数据和运行机制如何正确工作；企业架构把视野向前延伸到战略和组织，向后延伸到迁移、投资和治理。二者连接起来，技术方案才不只是一个设计良好的新系统，而能成为企业真正完成变化的一部分。