第2章 微服务架构的边界划分：领域驱动设计、限界上下文、服务粒度、接口契约
2.1 边界划分的核心矛盾
微服务架构的成功首先取决于边界划分的正确性。错误的边界导致服务间过度耦合、数据一致性灾难、部署成本飙升。边界划分需同时回答三个问题：业务归属（某个功能属于哪个服务）、通信方式（同步/异步、事件/请求）、数据主权（数据库归属与共享）。领域驱动设计（DDD）提供的限界上下文（Bounded Context）是解决这些问题的标准理论框架。
2.2 限界上下文：业务边界的最小单元
限界上下文是DDD中定义业务边界的核心模式。每个上下文拥有独立的领域模型、通用语言和数据存储。跨上下文通信必须通过显式的上下文映射（Context Map）策略，如防腐层（ACL）、共享内核（Shared Kernel）、发布/订阅事件。
| 映射策略 | 适用场景 | 耦合度 | 数据同步方式 |
|---|---|---|---|
| 防腐层（ACL） | 与遗留系统或外部系统集成 | 低 | 可独立演进，转换模型 |
| 共享内核（Shared Kernel） | 需要高频协作的紧密团队 | 高 | 共享领域层代码或公共库 |
| 客户/供应商（C/S） | 上下游依赖明确，下游主导 | 中 | API合约耦合，版本协商 |
| 就事论事（Separate Ways） | 完全独立、无需通信的子域 | 无 | 不交互 |
2.3 服务粒度：从聚合根到功能单元
服务粒度由聚合根（Aggregate Root）的边界决定。一个典型原则：一个服务应封装一个完整的聚合根，且该聚合根内部的事务边界必须完全落在服务内部。以下粒度级别需谨慎选择：
- 原子级服务（单个实体）：粒度太细，跨服务调用链过长，延迟剧增，调试困难。
- 聚合级服务（一个聚合根及其关联值对象）：推荐粒度，事务边界清晰，单一职责。
- 域级服务（多个聚合根）：粒度太粗，易导致数据冗余和局部过时，违背微服务独立演进初衷。
拆分的可操作性标准：每个服务应能独立部署、独立存储、独立扩容，且变更一个服务不强制同时变更其他服务。若发现两个服务之间存在频繁的两阶段提交（XA），说明边界划分错误。
2.4 接口契约：信任链路的显式约定
跨边界通信必须依赖契约而非隐式假设。接口契约包含语义契约（业务含义）、语法契约（数据结构与类型）、时序契约（调用顺序与幂等性）和质量契约（响应时间、可用性、限流策略）。
| 契约维度 | 描述 | 风险点 |
|---|---|---|
| 语义契约 | 接口的行为含义，例如“创建订单”包含库存扣减与支付预锁定 | 上下游理解不一致，导致业务逻辑遗漏 |
| 语法契约 | 请求/响应字段格式、类型、可选性 | 字段新增缺少版本协商，导致下游反序列化失败 |
| 时序契约 | 调用顺序要求（先鉴权后下单）、幂等性策略 | 非幂等操作重复执行造成数据重复 |
| 质量契约 | 接口超时阈值、熔断降级策略、并发上限 | 超时设置不匹配导致级联故障 |
2.5 数据流、控制流与信任链路
数据流遵循“所有数据修改只能由数据所有者触发”原则。跨边界的读操作应通过缓存副本或发布的事件视图完成，避免直接远程查询。控制流指服务编排或状态机驱动：若业务流程跨越3个以上服务，建议引入全局编排器（Saga / 工作流引擎）而非点对点网状调用。信任链路指服务间身份与权限的传递：采用JWT令牌或服务网格mTLS，保证每个请求携带来源上下文，下游根据调用者身份执行数据隔离。
一个典型的信任链路示例：用户请求经网关 → 令牌注入 → 订单服务调用支付服务 → 支付服务需验证令牌中用户ID是否与订单用户ID一致，防止越权操作。
2.6 选型权衡与风险点
- 领域复杂度 vs 服务数量：过度细化造成“分布式单体”困境——调用链长、事务复杂、监控难度增加；过度粗化又失去独立演进优势。推荐每个限界上下文控制在6~15个聚合根，服务数量与团队人数呈线性关系（2~4个服务/团队）。
- 事件驱动 vs 请求/响应：事件驱动提升松耦合和异步能力，但增加消息中间件依赖和最终一致性复杂度。建议核心链路（如支付）采用同步+幂等，非核心链路（如通知）采用异步事件。
- 共享数据 vs 数据独立：严格避免跨服务的数据库直接查询。若必须共享引用数据（如用户基本信息），采用事件广播副本而非直接join。
2.7 落地步骤与验收标准
- 步骤一：业务领域分析，产出限界上下文图（Context Map）和聚合根清单。
- 步骤二：为每个限界上下文定义防腐层策略和事件发布/订阅点。
- 步骤三：设计接口契约模板，包含语法、语义、时序、质量四维描述。
- 步骤四：搭建契约测试框架，每次发布前自动验证正向与异常场景。
- 步骤五：建立信任链路基线：统一令牌格式、服务间认证中间件、审计日志。
- 步骤六：通过压力测试验证质量契约（超时、限流、熔断）在实际集群中的表现。
验收标准：
- 每个服务可单独部署并在不修改其他服务的情况下完成功能交付（独立版本发布）。
- 跨服务调用全部经过契约测试，覆盖率达到100%的公共接口。
- 单次端到端业务请求（如创建订单）中，跨服务调用次数不超过5次，且无循环依赖。
- 任意服务宕机后，其上游服务能在约定时间内（如500ms）切换到降级逻辑，不阻塞整体流程。