领域战略建模：解密客户-供应者模式（Customer-Supplier）的契约规范

在大型分布式微服务系统中，限界上下文（Bounded Context）通常由不同的研发团队独立开发与维护。当两个上下文存在上下游依赖关系（如：上游“商品上下文”输出变更，下游“推荐系统”消费并展现）时，团队之间的协作效率直接决定了系统的交付周期。

如果上游改动接口时从不通知下游，或者下游提了接口改动需求后上游无限期推迟，这就会演变成典型的协作灾难。为了从组织架构和契约技术上保障上下游的敏捷协作，领域驱动设计（DDD）推荐使用**客户-供应者模式（Customer-Supplier）**。

本文将系统拆解客户-供应者模式的战略定位、协作保障三阶段流程、以及基于**契约测试（Contract Testing）**的自动化回归校验实战。

一、 核心范式对比：遵从者 (Conformist) vs. 客户-供应者 (Customer-Supplier)

当两个限界上下文确立上下游依赖关系时，研发团队可以采取不同强度的协作模式：

二、 客户-供应者模式自动契约测试流转拓扑

为了保障供应者（上游）发布的 API 不会悄悄击穿客户（下游）系统，通常采用**消费者驱动的契约测试（PACT）**进行拦截防护：

      [ 客户团队 (Consumer/下游) ] ── 1. 定义本域期望的 API 契约 json
                   │
                   ▼ 2. 推送至共享的契约存储中心
         [ 契约注册中心 (Pact Broker) ]
                   │
     ┌─────────────┴─────────────┐
     ▼ 3. 触发自动化构建管道      ▼ 3. 运行期拦截校验
[ 供应者流水线 (Supplier CI) ]  [ 供应者微服务 (Provider/上游) ]
     │                                   │
     ├─ 4. 从注册中心下载当前契约         ├─ 5. 模拟发送真实的 HTTP 请求
     ├─ 6. 自动执行 API 契约回刷校验     └─ 7. 比对响应结果与契约是否一致
     │
     ▼ 8. 判定发布包是否安全
【 校验通过 ──> 允许上游发布上线 ； 校验失败 ──> 强行中止构建，拦截故障传播 】

三、 代码实战：在 Java 中落地消费者驱动的契约测试

以下代码展示了下游（客户）如何使用 Pact 框架声明其对上游（供应者）API 的依赖预期，并在上游执行回归验证：

1. 下游（客户）编写：声明所期望的 API 契约（Consumer side）

package com.company.sales.consumer;

import au.com.dius.pact.consumer.dsl.PactDslWithProvider;
import au.com.dius.pact.consumer.junit.PactProviderRule;
import au.com.dius.pact.consumer.junit.PactVerification;
import au.com.dius.pact.core.model.RequestResponsePact;
import au.com.dius.pact.core.model.annotations.Pact;
import org.junit.Rule;
import org.junit.Test;
import static org.assertj.core.api.Assertions.assertThat;

public class MemberApiContractTest {

    @Rule
    public PactProviderRule mockProvider = new PactProviderRule("member-provider", this);

    /**
     * 1. 客户定义契约内容：下游希望调用 GET /members/100 时，上游响应 UID 和 Nickname
     */
    @Pact(consumer = "order-consumer")
    public RequestResponsePact createPact(PactDslWithProvider builder) {
        return builder
            .given("Member 100 exists")
            .uponReceiving("A request for member details")
                .path("/members/100")
                .method("GET")
            .willRespondWith()
                .status(200)
                .body("{"uid":"100", "nickname":"Alex"}")
            .toPact();
    }

    @Test
    @PactVerification
    public void runTest() {
        // 下游模拟发起调用，确保契约本身逻辑闭环
        String response = restTemplate().getForObject(mockProvider.getUrl() + "/members/100", String.class);
        assertThat(response).contains("Alex");
    }
}

2. 上游（供应者）运行：契约自动化验证（Provider side）

package com.company.sales.provider;

import au.com.dius.pact.provider.junit.Provider;
import au.com.dius.pact.provider.junit.State;
import au.com.dius.pact.provider.junit.loader.PactFolder;
import au.com.dius.pact.provider.junit.target.HttpTarget;
import au.com.dius.pact.provider.junit.target.Target;
import au.com.dius.pact.provider.junit.target.TestTarget;
import org.junit.runner.RunWith;

/**
 * 上游自动化验证入口
 * 职责：运行并拦截校验自身代码是否违背了下游制定的契约
 */
@Provider("member-provider")
@PactFolder("target/pacts") // 指定存放契约 JSON 文件的目录
public class ContractVerificationTest {

    @TestTarget
    public final Target target = new HttpTarget("localhost", 8080); // 上游本地服务地址

    @State("Member 100 exists")
    public void toState() {
        // 在本地数据库或 Mock 挡板中准备测试桩数据，使 /members/100 能够正常响应
        System.out.println("[Supplier CI] 正在加载状态数据: Member 100 exists");
    }
}

四、 总结

客户-供应者模式（Customer-Supplier）是提升跨限界上下文团队协作张力、杜绝沟通内耗的“敏捷催化剂”。

It 通过**在组织战略上确立下游优先权，终结了上游随意改动 API 导致的下游被动修复惨剧；并引入了消费者驱动的契约测试（PACT），将繁杂的人工沟通沉淀为自动化拦截工具，达成了分布式接口安全迭代的闭环控制**。掌握这套协作契约机制与 Pact 自动回归测试代码，是承担多微服务集群协作重构、保障大团队无缝高效交互 of 核心看家本领！