引言：当"巨石"成为负担

在很多大型企业的IT版图中，都有一座或几座"巨石"——那些运行了十年以上、代码量数百万行、承载着核心业务逻辑的单体系统。它们曾经是企业的技术基石，支撑着业务从起步到壮大的全过程。但随着数字化转型的深入，这些巨石系统逐渐显露出疲态：每次功能变更都需要全量发布，一个小需求可能牵动几十个模块的联调，新技术栈无法引入，团队新人需要半年才能上手。

有句话说，系统的复杂度不会消失，只会转移。当单体系统的复杂度超过人类认知能力的边界时，架构的可组合性就不再是技术追求，而是生存需要。

所谓"可组合性"（Composability），指的是系统能够以标准化的方式被拆解、重组、替换，而不会对整体功能造成不可预知的副作用。这个概念并非新生事物——SOA（面向服务的架构）在二十年前就提出了服务化的愿景，TOGAF框架从第9版到第10版的演进也始终围绕"如何让企业架构更灵活地适应变化"这一核心命题展开。但真正将可组合性从理论推向实践，需要企业在架构治理、组织能力、技术平台三个维度同步发力。

本文试图回答一个问题：对于一个拥有大量遗留系统的大型企业，如何借助TOGAF 10的模块化架构方法论和SOA的参考架构经验，走出一条渐进式的可组合性改造路径。

一、“巨石系统"的困境：为什么必须改变

1.1 技术债务的累积效应

单体系统并非天生就是"巨石”。很多系统在最初设计时也有清晰的模块边界，但随着业务快速迭代、人员频繁更替、需求不断堆叠，模块之间的耦合逐渐加深，最终形成了一个"大泥球"（Big Ball of Mud）式的架构。

技术债务的累积通常遵循这样一个规律：

1.2 业务敏捷性的瓶颈

从业务视角看，巨石系统最大的问题不是"慢"，而是"不可预测的慢"。一个简单的营销活动配置，可能因为涉及订单、库存、支付、用户中心等多个子系统的联动，需要协调三个团队、经过四轮联调、等待两个发布窗口。在竞争对手已经用低代码平台在三天内上线类似功能的时代，这种响应速度意味着商业机会的流失。

1.3 人才与组织的恶性循环

巨石系统还会引发组织层面的问题。根据康威定律（Conway’s Law），系统的架构会映射组织的沟通结构。当一个系统是高度耦合的单体时，围绕它的团队也必然是高度耦合的——跨团队会议多、接口文档缺失、变更需要层层审批。这种环境下，优秀的工程师会感到挫败并选择离开，而留下的团队因为缺乏足够的能力进一步推动改造，形成恶性循环。

二、TOGAF 10的模块化架构理念

2.1 从TOGAF 9到TOGAF 10：模块化是核心进化

TOGAF（The Open Group Architecture Framework）作为企业架构领域最具影响力的框架之一，在其第10版中做了一个重要的结构性调整：将原本厚重的单一文档体系拆分为"TOGAF Fundamental Content"（基础内容）和"TOGAF Series Guides"（系列指南）两个层次。

这个变化本身就体现了模块化思维：

• 基础内容定义了企业架构的核心概念、ADM（Architecture Development Method）方法论的骨架，这些是相对稳定的、普适的部分。
• 系列指南则针对特定场景（敏捷架构、数字化转型、安全架构等）提供具体的实践指导，这些是可以按需选取、独立更新的部分。

这种"稳定内核 + 可插拔指南"的结构，正是模块化架构在方法论层面的映射。

2.2 ADM方法论中的演进式架构思想

TOGAF的ADM（架构开发方法）是一个八阶段的迭代循环：

1. 架构愿景（Phase A） — 定义改造的目标与范围
2. 业务架构（Phase B） — 梳理业务能力与价值流
3. 信息系统架构（Phase C） — 规划数据与应用的服务化边界
4. 技术架构（Phase D） — 选择支撑可组合性的技术平台
5. 机会与解决方案（Phase E） — 识别可组合的改造机会点
6. 实施规划（Phase F） — 制定分阶段的迁移路线
7. 迁移规划（Phase G） — 执行渐进式迁移
8. 架构治理（Phase H） — 持续监控架构健康度

关键在于，ADM不是一个"推倒重来"的方法论，而是一个"渐进演进"的框架。每个迭代周期可以聚焦于一个业务领域或一个技术域，逐步将巨石系统拆解为可组合的架构单元。

2.3 Architecture Building Blocks（ABB）与Solution Building Blocks（SBB）

TOGAF框架中有一对核心概念值得深入理解：

• ABB（架构构建块）：定义"需要什么能力"，是对功能需求的抽象描述，不涉及具体实现。例如"用户身份认证能力"、“订单处理能力”。
• SBB（解决方案构建块）：定义"用什么来实现"，是ABB的具体技术落地。例如"OAuth2.0 + JWT的身份认证服务"、“基于事件驱动的订单处理引擎”。

在可组合性改造中，ABB/SBB的思路提供了一种从"功能视角"到"实现视角"的桥梁。企业可以先在ABB层面梳理出业务能力图谱，再逐步为每个ABB匹配可独立部署、可复用的SBB。这个过程天然就是模块化的过程。

三、SOA参考架构：可组合性的技术基石

3.1 SOA的核心原则回顾

SOA（Service-Oriented Architecture）并非一种具体的技术，而是一组架构原则。其核心思想可以归纳为以下几条：

• 服务自治：每个服务拥有独立的生命周期，可以独立开发、部署、升级。
• 松耦合：服务之间通过标准化的接口通信，内部实现对消费者透明。
• 服务可发现：服务注册在目录中，消费者可以动态发现和绑定服务。
• 服务可组合：多个服务可以通过编排（Orchestration）或编舞（Choreography）组合成更复杂的业务流程。

有句话说，SOA的最大贡献不是技术上的，而是思维上的——它让企业第一次意识到，IT系统可以像乐高积木一样被拼装，而不是像雕塑一样被雕琢。

3.2 SOA参考架构的分层模型

在The Open Group发布的SOA参考架构白皮书中，SOA被划分为以下几个层次：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

┌─────────────────────────────────────────┐
│           业务流程层（Process）           │
├─────────────────────────────────────────┤
│           服务编排层（Orchestration）     │
├─────────────────────────────────────────┤
│           服务层（Services）              │
├─────────────────────────────────────────┤
│           服务组件层（Components）        │
├─────────────────────────────────────────┤
│           基础设施层（Infrastructure）    │
└─────────────────────────────────────────┘

每一层都有明确的职责边界和标准化的交互接口。业务流程层负责定义端到端的业务逻辑；服务编排层负责将原子服务组合为业务场景；服务层承载具体的业务能力；服务组件层是服务的物理实现；基础设施层提供运行环境、消息总线、安全认证等横切关注点。

3.3 SOA的历史教训：为什么很多企业没有走通

SOA的理念是先进的，但在2005-2015年的大规模实践中，很多企业并未取得预期效果。主要原因包括：

这些教训告诉我们：可组合性不仅仅是技术问题，更是治理和组织问题。TOGAF框架中的"架构治理"（Architecture Governance）阶段正是为了应对这一挑战而设计的。

四、可组合性改造的实操路径

4.1 第一阶段：架构评估与能力梳理

改造的第一步不是写代码，而是"看清现状"。这一步的核心工作包括：

业务能力图谱绘制

按照TOGAF Phase B（业务架构）的方法，将企业的核心业务能力进行梳理和分层。例如一家制造企业的能力图谱可能包含：

• 产品研发域：需求管理、设计仿真、BOM管理
• 供应链域：采购管理、库存控制、物流调度
• 生产制造域：排产计划、质量管控、设备管理
• 营销服务域：客户管理、订单处理、售后服务

每个业务能力对应一组IT系统，这些系统之间的关系（数据流、控制流、依赖关系）需要被清晰地绘制出来。

耦合度分析

使用静态代码分析工具和运行时调用链追踪，量化系统间的耦合程度。关键指标包括：

• 扇入/扇出比：一个模块被多少其他模块调用（扇入），以及它调用多少其他模块（扇出）。扇出过高的模块是"上帝模块"的候选。
• 循环依赖数：模块A依赖B、B依赖C、C又依赖A的情况。循环依赖是模块化的天敌。
• 共享数据库表数量：多个系统直接读写同一张表的情况。这是最隐蔽也最难解的耦合形式。

4.2 第二阶段：服务边界识别与拆分策略

基于DDD的限界上下文识别

领域驱动设计（Domain-Driven Design）中的"限界上下文"（Bounded Context）概念，与SOA的服务边界有着天然的对应关系。一个限界上下文内的概念具有统一的语义，不同限界上下文之间通过"上下文映射"（Context Mapping）定义交互方式。

在实践中，识别限界上下文可以遵循以下线索：

1. 术语冲突：同一个词在不同业务场景中有不同含义。例如"订单"在销售部门指的是客户购买请求，在生产部门指的是生产任务单，在财务部门指的是应收凭证。术语冲突通常意味着上下文边界。
2. 数据模型差异：同一个实体在不同系统中的字段集合差异很大。这说明不同业务域对该实体的关注点不同，应当各自维护自己的模型。
3. 变更频率差异：如果一组功能每月都在迭代，而另一组功能半年才动一次，它们大概率属于不同的演进节奏，应当解耦。

绞杀者模式（Strangler Fig Pattern）

对于遗留系统的改造，“绞杀者模式"是最稳妥的拆分策略。其核心思想是：不直接修改旧系统，而是在旧系统外围逐步构建新的服务，将功能一点点"绞杀"过来，直到旧系统可以被安全下线。

具体步骤：

1. 识别候选功能：选择变更频率高、业务价值大、耦合度相对低的功能作为首批拆分对象。
2. 建立代理层：在旧系统前方部署一个API网关或代理服务，将外部流量统一接入。
3. 逐步切流：新功能在新服务中实现，老功能通过代理层逐步从旧系统迁移到新服务。
4. 监控与回退：每次迁移后密切监控业务指标，确保功能正确性，保留快速回退能力。

4.3 第三阶段：可组合性基础设施建设

API网关与服务网格

可组合性需要强大的基础设施支撑。API网关负责统一的流量管理、认证鉴权、限流熔断；服务网格（Service Mesh）则在更细粒度上管理服务间通信的可观测性、安全性和弹性。

事件驱动架构（EDA）

如果说API是同步的"请求-响应"模式，那么事件驱动架构就是异步的"发布-订阅"模式。在可组合架构中，EDA的价值在于：

• 解耦时间依赖：生产者和消费者不需要同时在线。
• 解耦逻辑依赖：生产者不需要知道谁在消费事件。
• 支持事件溯源：所有状态变更都以事件形式记录，支持任意时间点的状态重建。

在实践中，企业消息总线（如Kafka、RabbitMQ）通常作为EDA的基础设施，而"领域事件”（Domain Event）的设计则需要遵循DDD的原则——事件应当反映业务事实，而非技术操作。

数据解耦与数据网格

共享数据库是巨石系统最常见的耦合形式，也是最难解决的问题。数据解耦的策略包括：

• 数据库拆分：每个服务拥有自己的数据库（Database per Service），通过API或事件同步数据。
• CQRS（命令查询职责分离）：写操作走命令模型，读操作走查询模型，两者可以独立优化。
• 数据网格（Data Mesh）：将数据视为产品，每个业务域对自己的数据产品负责，通过标准化的数据产品接口对外提供数据服务。

4.4 第四阶段：治理体系与持续演进

架构适应度函数（Fitness Functions）

借鉴演化架构（Evolutionary Architecture）的理念，企业可以为架构的可组合性定义一组"适应度函数"，在CI/CD流水线中自动检测：

• 模块间的循环依赖是否增加
• 服务间的API契约是否被破坏
• 跨服务调用链的延迟是否在可接受范围内
• 数据库共享表的访问是否在减少

这些适应度函数就像架构的"体检指标"，让团队能够在每次变更后立即了解架构健康度的变化。

服务目录与能力市场

可组合性的终极目标是让业务能力像"商品"一样被浏览、选择和组合。这需要一个完善的服务目录（Service Catalog）或能力市场（Capability Marketplace），其中：

• 每个服务都有清晰的描述、版本信息、SLA承诺
• 服务消费者可以自助申请接入
• 服务提供者可以看到调用统计和反馈

TOGAF框架中的"架构仓库"（Architecture Repository）概念与此高度契合——它不仅是架构资产的存储库，更是架构决策的治理平台。

五、组织适配：康威定律的实践

5.1 从技术团队到业务团队

可组合性改造不仅是技术重构，更是组织重构。传统的IT组织通常按技术栈划分团队（Java团队、前端团队、DBA团队），这种结构天然倾向于产生技术层面的单体系统。

向可组合架构演进，需要组织也走向"业务域对齐"的团队结构：

• 每个团队负责一个完整的业务能力（端到端）
• 团队拥有该能力范围内从需求到运维的全部自主权
• 团队之间通过标准化的API契约协作，而非会议和文档

5.2 平台工程团队的角色

在可组合架构中，需要一个专门的"平台工程"团队来维护基础设施层——API网关、服务网格、消息总线、监控体系等。这个团队的职责不是替业务团队做技术选型，而是提供"铺好的路"（Paved Road），让业务团队在这条路上走得又快又稳。

平台工程团队的成功标准不是"我们提供了多少工具"，而是"业务团队的认知负荷降低了多少"。

5.3 架构治理委员会的运作

TOGAF框架中强调的"架构委员会"（Architecture Board）在可组合性改造中扮演着关键角色。其核心职责包括：

• 审批服务边界的划分和变更
• 维护架构原则和技术标准
• 评审重大架构决策
• 监控架构适应度函数的趋势

架构委员会不应成为"审批瓶颈"，而应是"守护者"——确保改造方向不偏离，同时给予团队足够的自主空间。

六、演进式改造的节奏把控

6.1 不要追求"一步到位"

可组合性改造最大的风险不是技术风险，而是"改造本身成为了新的巨石项目"——试图一次性设计完美的目标架构，然后花三年时间迁移。这种"大爆炸式"的改造几乎注定失败。

正确的节奏是"小步快跑、持续交付价值"：

1. 每季度选择一个业务域作为改造焦点
2. 每个迭代周期（2-4周）交付一个可独立运行的服务
3. 每次迁移后立即验证业务指标，确保改造没有引入回归问题
4. 定期回顾架构适应度函数，调整改造优先级

6.2 迁移优先级矩阵

不是所有系统都需要改造，也不是所有系统都应该在同一时间改造。一个实用的优先级评估框架：

最佳策略是先从"高业务价值 + 低耦合度"的系统入手，积累经验和信心后再挑战更复杂的领域。

6.3 新旧系统的共存策略

在改造过程中，新旧系统不可避免地需要长期共存。这需要解决几个关键问题：

• 数据一致性：新旧系统可能同时操作同一份数据，需要通过双写、事件同步或CDC（Change Data Capture）保证数据一致。
• 流量切换：通过功能开关（Feature Toggle）和流量染色（Traffic Tagging）实现灰度切换。
• 统一可观测性：无论流量走新系统还是旧系统，都应在同一个监控面板中可见。

七、可组合性的度量与持续改进

7.1 可组合性成熟度模型

企业可以用一个五级成熟度模型来评估自身的可组合性水平：

• Level 1 — 单体阶段：系统高度耦合，发布周期以月计，团队按技术栈组织。
• Level 2 — 初步拆分：部分功能被拆分为独立服务，但数据层仍然共享，服务间存在大量同步调用。
• Level 3 — 服务化阶段：核心业务能力以服务形式暴露，拥有独立的数据库和API契约，但服务编排仍然依赖中心化流程引擎。
• Level 4 — 可组合阶段：服务粒度合理，事件驱动架构覆盖核心业务流程，服务可以被灵活组合以支持新的业务场景。
• Level 5 — 自适应阶段：架构具备自适应能力，能够根据负载、故障、业务变化自动调整组合方式，平台工程团队提供完善的自助服务能力。

7.2 关键度量指标

八、面向未来的架构思维

8.1 可组合性与AI的交汇

随着大模型技术的成熟，可组合性架构将获得新的可能性。AI能力（自然语言理解、智能决策、内容生成）可以作为标准化的"AI服务"嵌入到可组合架构中，而不需要与业务系统深度耦合。例如：

• 客户服务域可以组合"智能问答服务"和"人工坐席服务"，根据问题复杂度动态切换。
• 供应链域可以组合"需求预测AI服务"和"传统规则引擎"，在预测精度和可解释性之间取得平衡。

可组合性架构为AI能力的引入提供了天然的"插槽"——只要AI服务遵循标准化的接口契约，就可以像替换任何其他组件一样被引入或替换。

8.2 从SOA到可组合：一脉相承的演进

回顾整个技术演进脉络，可以看到一条清晰的逻辑线：

SOA提出了"服务化"的愿景 → 微服务将服务粒度推向极致 → 可组合性在服务化的基础上强调"灵活重组"的能力 → TOGAF 10从方法论层面为这一演进提供了治理框架。

这条线背后的核心驱动力始终没有变：让企业的IT系统能够以可预测的成本和风险，快速响应业务的变化。技术在变，工具在变，但"让架构服务于业务敏捷性"这一目标从未改变。

结语

从"巨石系统"走向模块化演进，不是一次性的项目，而是一场持续的旅程。它需要架构师具备TOGAF所倡导的"企业级视野"——不仅看到技术层面的拆分与重组，更要理解业务能力、组织结构、治理机制之间的深层关联。

SOA的历史经验告诉我们，纯粹的技术驱动无法实现真正的可组合性；TOGAF 10的模块化方法论则提示我们，方法论本身也需要模块化——没有放之四海而皆准的模板，只有适配于特定企业上下文的裁剪与实践。

最终，可组合性架构的价值不在于架构图上的"漂亮方框"，而在于：当业务需要一个新能力时，团队能够在几天内将已有的服务组件重新组合并交付上线，而不是花三个月在巨石系统中凿出一条裂缝。这才是架构演进的终极目标——让技术成为业务创新的加速器，而非绊脚石。