3. 领域边界识别：限界上下文（Bounded Context）的划分原则、上下文映射图

在调度系统的领域驱动设计中，限界上下文（Bounded Context）是划分领域边界、控制模型一致性的核心战术工具。一个调度系统往往包含多个子领域（如任务管理、资源分配、执行引擎、监控告警），每个子领域都有自己独立的通用语言和模型边界。错误的边界划分会导致模型污染、团队协作混乱、系统耦合膨胀。

3.1 限界上下文的划分原则

划分限界上下文时，应遵循以下五项核心原则，确保每个上下文内部高内聚、上下文之间低耦合：

3.2 上下文映射图（Context Map）

上下文映射图是描述限界上下文之间协作关系的可视化工具。它帮助团队理解系统集成方式、模型转换策略以及团队间的协作模式。调度系统中常见的映射关系包括：

• 合作关系（Partnership）：两个上下文协同完成一个业务目标，如任务上下文与调度上下文共同决定任务何时执行。
• 共享内核（Shared Kernel）：共享一小部分核心模型，如任务状态枚举在多个上下文中保持一致。
• 客户-供应商（Customer-Supplier）：上游上下文（供应商）提供数据或服务，下游上下文（客户）依赖上游，如资源上下文为调度上下文提供可用资源列表。
• 防腐层（Anti-Corruption Layer）：下游上下文通过适配器隔离上游模型的变更影响，如执行引擎上下文通过ACL适配外部云平台的资源模型。
• 开放主机服务（Open Host Service）：上下文以标准协议（如REST/gRPC）对外提供服务，如监控上下文提供统一的告警查询API。
• 发布语言（Published Language）：使用标准数据格式（如Protobuf、JSON Schema）进行模型交换，如任务定义使用标准Schema在上下文间传递。

3.3 调度系统上下文映射图（SVG）

下图展示了一个典型调度系统的上下文映射关系，包含6个限界上下文及其协作模式：

3.4 上下文映射的代码体现：防腐层示例

以下Go代码展示了执行引擎上下文如何通过防腐层（ACL）隔离外部Kubernetes资源模型的变更：

// 执行引擎上下文内部模型：资源定义
type Resource struct {
    ID        string
    Name      string
    Capacity  int
    Available int
}

// 防腐层：将Kubernetes资源模型转换为内部模型
type KubernetesACL struct {
    client kubernetes.Interface
}

func (acl *KubernetesACL) ToInternalResource(k8sRes *v1.Node) *Resource {
    return &Resource{
        ID:        string(k8sRes.UID),
        Name:      k8sRes.Name,
        Capacity:  int(k8sRes.Status.Capacity.Cpu().MilliValue()),
        Available: int(k8sRes.Status.Allocatable.Cpu().MilliValue()),
    }
}

// 调度决策上下文只依赖内部Resource模型，不感知K8s
type Scheduler struct {
    resourceRepo ResourceRepository
}

func (s *Scheduler) Schedule(task *Task) (*Resource, error) {
    resources := s.resourceRepo.FindAvailable(task.RequiredCapacity)
    // 调度逻辑...
    return resources[0], nil
}

3.5 上下文映射的演进策略

调度系统的上下文映射不是一成不变的，随着业务发展和技术演进，映射关系需要持续调整：

1. 阶段一（单体原型）：所有逻辑在一个上下文中，使用共享内核模式快速验证。
2. 阶段二（按能力拆分）：将任务、调度、执行拆分为独立上下文，采用客户-供应商模式。
3. 阶段三（引入外部系统）：对接Kubernetes、云平台时，增加防腐层保护核心模型。
4. 阶段四（开放生态）：将监控、告警等能力以开放主机服务模式暴露给其他系统。