把服务边界看成耦合与自治的交换：远程 API 不能消灭领域耦合

订单每次更新都要同步调用优惠、库存、支付与内容五个服务，且必须同时发布才能兼容——这只是把模块调用换成了网络。本页定义三种耦合、边界验证方法与同步/事件的真实交换。

三种耦合决定边界质量

边界设计要同时检查变更耦合、运行耦合和数据耦合。两个模块若总是一起修改，可能还没有稳定契约；若部署独立但每次请求都同步调用对方，仍存在运行耦合；若双方直接写同一数据库表，则数据所有权并未分开。只有边界两侧能独立演进并承担故障处理，部署拆分才形成实际自治。

模块化单体可先通过依赖规则、接口和独立测试建立逻辑边界，保留进程内调用的低延迟和简单事务。当出现独立扩缩、故障隔离或团队交付需求时，再测量将一个边界移出进程所引入的网络、部署、数据和运维成本。若跨边界事务仍不可避免，拆分可能只是把锁等待改成分布式协调。

远程API不能消灭领域耦合

边界应围绕业务不变量、数据主权和变化节奏，而不是每张表一个服务。把"创建订单并扣库存"拆开后，原本本地事务变为跨资源状态机；若业务不容忍预留与确认中间态，这个边界可能不合适。按团队方便拆分也需核对写域，不能把协调责任留给调用方拼接所有内部字段。

同步与事件的真实选择

同步调用给即时答复，带来可用性和延迟依赖；事件降低时间耦合，却增加重复、乱序、schema、重放和最终状态查询。事件通知不等于领域完全解耦：消费者依赖字段含义、时序和历史，删除字段可能比同步API升级更难。事件投影的机制由CDC、事件和投影权威讲授。

假设四个串行依赖各正常可用99.9%，仅在独立且全部必需的简化模型下乘积约99.6006%；真实相关故障不能直接乘。若其中两个改为允许延迟的投影，可减少关键同步依赖，但必须新增陈旧与恢复预算，而不是凭空得到更高正确性。

边界验证

画变更依赖矩阵：一次需求需要哪些团队、字段、部署、数据库迁移与值守配合。比较按技术层和按业务能力两种拆分，对十个典型变更逐项推演。执行一个兼容变更和一次失败恢复演练，观察消费者是否可独立升级、能否从事件重建。

架构师应给契约、责任与例外，而非只画服务框。跨边界高频强事务持续出现时，可考虑合并写域或保留模块化结构；自治是一种需要付费的能力，不是服务数量。生命周期的经济比较见总拥有成本和单位经济。

组织-边界对齐检查：康威映射不是画组织架构图

本页前面讲服务边界是耦合与自治的交换，组织维度还需要一次显式检查：边界画出来了，组织真的能独立交付、独立值班、独立理解吗？三项检查分别是共享写库、值班覆盖与认知负载。

共享写库检查：若两个"独立"服务仍直接写同一批表（本例 2 张共享写表），数据所有权没有分开，任何 schema 变更都要跨团队协调，自治是表象。值班覆盖检查：新边界若没有独立值班或明确的升级路径，事故时仍要原团队兜底，拆分没有减少耦合。认知负载检查：一个团队负责超过 5 个模块时，理解成本与交接成本上升，边界数量超过组织容量。

反例算例：4 个团队、2 张共享写表、值班有覆盖、单团队负责 7 个模块。检查输出 problems=["shared-write-db","cognitive-overload"]、verdict=NOT_AUTONOMOUS——即使部署上分成了多个服务，数据与认知两层都没有自治。正确动作不是继续拆，而是先消除共享写表（把数据所有权划给一个团队）或降低模块负载。

检查要与变更矩阵联动：取十个典型变更，逐项看需要几个团队、几次数据库迁移、几次同步发布。若多数变更仍跨团队，边界只是部署单元，不是自治单元。这一步回指本页前面的"三耦合"分析。

执行 python3 labs/evolution_models.py boundary_alignment：输入上述四个参数，预期输出两项问题与 NOT_AUTONOMOUS。脚本只做规则检查，不测量真实团队协作数据。

两个合理选择：A 先按目标架构拆服务，组织随后调整（"架构驱动组织"），推进快但过渡期协调成本高；B 先消除共享写库、补齐值班与认知负载，再拆服务（"组织就绪再拆"），慢但每一步都可验证。本例选 B，并把三项检查作为拆分前置条件写入 ADR。

架构师变化条件

把"订单+库存"合并回一个写域而其余保持事件：跨边界强事务消失，代价是部署与故障域重新合并——用变更矩阵验证哪十个典型变更受益。若五依赖中有两个改为可延迟投影，端到端 SLO 要为陈旧数据新增预算（见可用性、耐久性和正确性是不同质量目标）。每次变化重画变更依赖矩阵并推演失败恢复。

闭卷验收

本页 8 道闭卷题收进了下方自测面板：先回忆，再展开参考答案与评分点，最后给三档自评。