领域战略协作：解密限界上下文集成模式（Shared Kernel/OHS/PL）与选择

在大型企业级分布式系统中，不同的限界上下文（Bounded Context，通常对应不同的微服务）绝对不是孤立存在的。它们之间为了完成特定的商业流转，必须开展频繁的协同交互。

然而，如果任由开发团队在微服务间随意发起 API 调用，系统内部就会迅速退化为复杂的网状依赖，导致“牵一发而动全身”。

为了科学治理微服务之间的协作关系，明确团队职责并阻断依赖混乱，领域驱动设计（DDD）提出了**限界上下文集成模式（Bounded Context Integration Patterns）**。

本文将系统拆解共享内核（Shared Kernel）、开放主机服务（OHS）、发布语言（PL）等核心集成模式 of 物理定义与适用边界。

一、 上下文集成模式的核心分类矩阵

DDD 根据协作紧密程度、上下游权力关系（Power Relationship）将上下文集成划分为以下六种经典模式：

二、 OHS 与 PL 模式的数据交互流转拓扑

当多个下游限界上下文同时向一个通用的“会员系统”拉取用户状态时，典型的 OHS + PL 集成流转拓扑如下：

                   [ 上游: 会员限界上下文 (Member Context) ]
                                    │
                                    ▼ 1. 暴露标准 OHS 开放服务门面 (Facade)
                        [ 开放主机服务 (OHS) ]
                                    │
                        ▼ 2. 统一输出平台无关的 JSON 数据结构
                        [ 发布语言 (PL) ] ──> 定义传输标准: MemberInfoDTO
                                    │
             ┌──────────────────────┼──────────────────────┐
             ▼ (拉取同步)            ▼ (拉取同步)            ▼ (拉取同步)
       [ 下游: 订单微服务 ]    [ 下游: 促销微服务 ]    [ 下游: 物流微服务 ]
       - 采用防腐层 (ACL)      - 直接依赖 (Conformist) - 采用防腐层 (ACL)

三、 代码实战：在共享内核（Shared Kernel）中定义不可变共享值对象

在不得不采用“共享内核”以加快多个内部服务数据流转的场景下，共享内核包中声明的模型必须是**绝对只读、高表达力且不可篡改的**：

package com.company.sharedkernel.domain;

import java.io.Serializable;
import java.util.Objects;

/**
 * 共享内核实体：不可变地理坐标值对象（Shared Value Object）
 * 规约：此 JAR 包由 Sales 域与 Delivery 域共同依赖，仅允许追加属性，严禁单方面修改
 */
public final class GeoLocation implements Serializable {
    
    private final double longitude;
    private final double latitude;

    public GeoLocation(double longitude, double latitude) {
        // 不变性校验
        if (longitude < -180 || longitude > 180) {
            throw new IllegalArgumentException("经度超出物理范围！");
        }
        if (latitude < -90 || latitude > 90) {
            throw new IllegalArgumentException("纬度超出物理范围！");
        }
        this.longitude = longitude;
        this.latitude = latitude;
    }

    public double getLongitude() { return longitude; }
    public double getLatitude() { return latitude; }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        GeoLocation that = (GeoLocation) o;
        return Double.compare(that.longitude, longitude) == 0 &&
               Double.compare(that.latitude, latitude) == 0;
    }

    @Override
    public int hashCode() {
        return Objects.hash(longitude, latitude);
    }
}

四、 总结

限界上下文集成模式的设计，是保证大型分布式系统拓扑整洁、研发团队高效分工的“金钥匙”。

It 通过**基于接口 of 依赖倒置设计，确保了数据库存储介质（SQL/NoSQL） of 更迭不会向核心领域代码渗透，保障了领域逻辑 of 高度纯净与可测试性**；并**通过面向聚合根 of 集合装配模式，强行守护了聚合根 of 事务与业务一致性边界**。掌握这套战略集成模式与共享内核代码规范，是主导多团队大型协作项目、保证微服务演进不失控 of 核心看家本领！