集成成熟度模型 = 5 级演进路径
一、业务问题
集成方式的演进有清晰的路径，Vernon 在 Ch 13 隐含给出 5 级成熟度：
Level 1：数据库共享（最差）
Level 2：RPC 集成（强耦合）
Level 3：REST 集成（资源导向）
Level 4：消息 + 事件（异步解耦）
Level 5：事件溯源 + CQRS（最完整）问题：如何从 Level 1 演进到 Level 5？何时该升级？
二、控制论视角
集成成熟度 = 系统解耦程度
类比：
Level 1：所有状态共享（强耦合）
Level 5：每个系统独立演化（自治）
钱学森 Ch 21：
- 集中控制 = Level 1-2
- 多级分散 = Level 3-4
- 自适应 + 协调 = Level 5Vernon 隐含的成熟度（基于 Ch 13）：
三、5 级成熟度详解
3.1 Level 1：数据库共享
特点：
- 多个 BC 共享一个数据库
- 直接 SQL join
- 表结构耦合
优势：
- 简单
- 强一致
劣势：
- 紧耦合
- 性能差
- 难以独立演化
- 反 DDD
评估：
- 适合：< 3 BC、业务简单
- 不适合：微服务架构3.2 Level 2：RPC 集成
特点：
- 同步调用
- SOAP / RPC / HTTP API
- 强耦合
优势：
- 简单直接
- 强一致
劣势：
- 同步阻塞
- 级联失败
- 性能差
- 难调试
评估：
- 适合：内部系统、强一致
- 不适合：跨系统、高性能3.3 Level 3：REST 集成
特点：
- 资源导向
- HTTP 语义
- 标准化
优势：
- 工具链成熟
- 标准化
- 可缓存
劣势：
- 同步（性能受限）
- URL 强耦合
- 不适合复杂流程
评估：
- 适合：CRUD、资源导向
- 不适合：业务流程3.4 Level 4：消息 + 事件
特点：
- 异步消息
- Pub/Sub 模式
- 事件驱动
优势：
- 异步解耦
- 故障隔离
- 适合业务流程
劣势：
- 复杂度高
- 最终一致
- 调试困难
评估：
- 适合：业务流程、跨 BC
- 不适合：强一致3.5 Level 5：事件溯源 + CQRS
特点：
- 完整事件流
- 状态可重放
- 读写分离
优势：
- 完整审计
- 时间旅行
- 性能极致
劣势：
- 复杂度最高
- 学习曲线
- 存储成本
评估：
- 适合：复杂业务、合规要求
- 不适合：简单业务四、5 级演进路径
Level 1 → Level 2：
- 拆数据库
- 用 RPC 通信
- 解决"巨型数据库"问题
Level 2 → Level 3：
- RPC → REST
- 资源化设计
- 解决"强耦合"问题
Level 3 → Level 4：
- REST → 消息
- 同步 → 异步
- 解决"同步阻塞"问题
Level 4 → Level 5：
- 消息 → 事件溯源
- 状态从事件派生
- 解决"状态可追溯"问题五、升级决策
5.1 何时升级
Level 1 → Level 2：
- 数据库成为瓶颈
- 多团队协作
- 独立部署需求
Level 2 → Level 3：
- 集成复杂
- 需要 REST 标准化
- 资源导向清晰
Level 3 → Level 4：
- 同步调用成为瓶颈
- 业务流程解耦需求
- 故障隔离需求
Level 4 → Level 5：
- 审计要求
- 状态可追溯需求
- 性能极致要求5.2 何时不升级
Level 1 足够：
- 业务简单
- 团队小
- 性能可接受
Level 2 足够：
- 强一致需求
- 内部系统
- 同步可接受
Level 3 足够：
- CRUD 为主
- 无复杂流程
Level 4 足够：
- 业务可最终一致
- 无审计要求六、工程实践
实战 1：评估当前成熟度
自评：
1. 跨 BC 数据库 join 比例
2. 同步 vs 异步调用比例
3. 是否有事件溯源
4. 性能瓶颈在集成层还是业务层
根据自评决定升级路径实战 2：渐进升级
反模式：一步到位升级到 Level 5
- 成本高
- 风险大
- 团队学习曲线
正模式：每次升一级
- 评估收益
- 试点一个 BC
- 全局推广实战 3：混合使用
现实情况：
- 核心业务用 Level 5
- 普通业务用 Level 3
- 简单报表用 Level 1
按 BC 选择合适的成熟度七、性能指标
| 指标 | 衡量 |
|---|---|
| 集成平均延迟 | P50 / P99 |
| 同步 vs 异步比 | 多少同步调用（应该低） |
| 跨 BC 数据库 join | 应该 0 |
| 事件处理 SLA | 消息处理延迟 |
八、边界判断
何时用 Level 1：
- 业务简单
- 团队小
- 单体应用
何时用 Level 2-3：
- 微服务架构
- 强一致需求
- 资源导向
何时用 Level 4-5：
- 业务流程复杂
- 跨系统集成
- 审计要求
九、与其他 L 层方法论的关系
| 方法论 | 关系 |
|---|---|
| api-design | Level 3 的具体实现 |
| event-contract | Level 4 的具体实现 |
| cqrs-es | Level 5 的核心 |
| compound-control（结构） | Level 4-5 |
| risk-driven-architecture | 决定升级时机 |
| architecture-evolution（主题） | 演进的子主题 |
十、钱学森原话
Ch 21 §21.3（多级分散）： "大系统的多级分散控制：每个子系统独立决策，又通过协调器保持全局目标一致。"
Ch 6 §6.7（耦合取舍）： "受控对象中的相互关联并不总是有害的"——不要为了解耦而解耦。
十一、总结
集成成熟度 = 5 级演进路径：
| Level | 方式 | 适用 |
|---|---|---|
| 1 | 数据库共享 | 单体 |
| 2 | RPC | 内部 |
| 3 | REST | 资源 |
| 4 | 消息 | 业务流程 |
| 5 | 事件溯源 + CQRS | 复杂业务 |
核心原则：
- 按需升级（不是越高越好）
- 每次升一级（不要跨级）
- 混合使用（不同 BC 不同级别）
- 风险驱动（按业务需求升级）
一句话总结：集成成熟度 = 5 级路径，按业务需求按需升级。
相关链接
L 层方法论
控制结构
业务主题
源典
- IDDD Ch 13（Integrating Bounded Contexts）
- 工程控制论 Ch 21（大系统理论 = Level 3-5）
- 工程控制论 Ch 6 §6.7（耦合取舍 = 集成方式选择）