边界与契约（Boundaries & Contracts）

边界 = 谁不能改我，契约 = 我答应你什么。本 group 解决 L2 第二问："模块 / 服务之间怎么说话？"

本 group 包含

文档	核心问题	V2 节点
Coupling Tradeoff	耦合多少算合适？	B6 权衡
API Design	接口如何设计？	B4 抽象 + B7 表达
Interface Contract	同步 RPC 的契约？	B4 抽象
Event Contract	异步事件的契约？	B7 表达 + Schema
Hyrum's Law	为什么契约会被"试探性使用"？	控制论 Ch 6 解耦
Deprecation Cycle	契约如何下架？	V2 B5 演化
Integration Maturity Model	集成风格的成熟度等级？	B3 + B6

边界与契约的 3 个层次

边界与契约 = 3 个层次
  1. 模块边界（代码层）   → package / namespace / module
  2. 服务边界（部署层）   → HTTP / gRPC / message
  3. 组织边界（团队层）   → 所有权 / 责任 / SLA

阅读顺序

coupling-tradeoff (基调：耦合不是越低越好)
    ↓
api-design (接口设计原则)
    ↓
interface-contract (同步 RPC 契约)
    ↓
event-contract (异步事件契约)
    ↓
hyrums-law (契约会被试探的现实)
    ↓
deprecation-cycle (契约下架)
    ↓
integration-maturity-model (整体成熟度等级)

与其他 group 的关系

• 上游：02-architecture（架构风格 → 接口形态）
• 下游：04-patterns（契约 → Saga / CQRS 模式）、L3-implementation（契约 → 代码生成）

关键洞察

边界与契约的核心不是"严格"——是"可演化"——

• 契约必须有版本（v1, v2, ...）
• 契约必须有 deprecation 周期（不是立即下架）
• 契约必须被监控（哪些调用方还没切？） 否则契约就是"装饰品"——3 个月后没人记得当时承诺过什么。

相关链接

• L2 Architecture——架构风格
• L2 Patterns——契约实现模式
• L1 Cross-Context——BC 关系 → 契约选型
• V2 B6 权衡——耦合权衡