📚 课程目录第4章服务边界划分原则

4. 服务边界划分原则：领域驱动设计(DDD)概述、限界上下文、聚合根与实体划分

在任务调度DAG系统中，服务边界的划分直接决定了系统的可维护性、可扩展性与团队协作效率。领域驱动设计（DDD）提供了一套成熟的理论体系，帮助我们将复杂的业务逻辑映射为清晰的软件模型。本节将围绕DDD的核心概念，阐述如何为任务调度DAG系统划定合理的服务边界。

4.1 领域驱动设计(DDD)概述

DDD是一种软件设计方法论，强调以业务领域为核心，通过统一语言（Ubiquitous Language）连接领域专家与开发团队。在任务调度场景中，领域专家可能是运维工程师、数据工程师或业务分析师，而“任务”、“DAG”、“调度策略”、“依赖关系”等术语构成了团队的统一语言。

核心价值： DDD帮助团队避免“技术实现绑架业务逻辑”的陷阱。在DAG调度系统中，这意味着调度引擎的代码结构应直接反映业务概念（如“任务节点”、“上下游依赖”、“重试策略”），而非底层数据库表结构或网络协议。

DDD的战略设计阶段主要关注限界上下文（Bounded Context）的划分，而战术设计阶段则聚焦于实体（Entity）、值对象（Value Object）、聚合根（Aggregate Root）等模式的具体实现。

4.2 限界上下文：服务边界的核心单元

限界上下文是DDD中定义服务边界的最重要概念。每个限界上下文拥有独立的统一语言、业务规则和数据模型。在任务调度DAG系统中，我们可以识别出以下典型的限界上下文：

限界上下文	核心职责	统一语言示例	对外接口风格
DAG编排上下文	管理DAG的定义、节点依赖关系、版本控制	DAG、节点、边、上游、下游、拓扑排序	RESTful API
任务调度上下文	触发任务执行、管理调度策略（定时、事件驱动）	调度器、触发器、调度计划、队列、优先级	gRPC / 消息队列
任务执行上下文	实际运行任务实例、管理执行状态、资源分配	执行器、Worker、任务实例、日志、重试	gRPC
监控告警上下文	采集执行指标、检测异常、发送告警通知	指标、阈值、告警规则、通知渠道、SLA	事件驱动 / Webhook

每个限界上下文对应一个独立的微服务或模块。上下文之间的通信通过上下文映射图（Context Map）来定义，常见的协作模式包括：

合作关系（Partnership）：两个上下文紧密协作，如DAG编排上下文与任务调度上下文之间需要同步DAG变更。
防腐层（Anti-Corruption Layer）：当一个上下文需要集成外部系统（如第三方调度引擎）时，通过防腐层隔离外部模型的污染。
开放主机服务（Open Host Service）：上下文对外提供明确的API协议，如任务执行上下文暴露gRPC接口供Worker调用。

4.3 聚合根与实体划分

在限界上下文内部，我们需要通过聚合（Aggregate）来组织领域对象。聚合是一组相关对象的集合，聚合根是聚合中唯一能被外部访问的入口。在任务调度DAG系统中，合理的聚合根设计能有效保证数据一致性和事务边界。

4.3.1 核心聚合根识别

限界上下文	聚合根	包含实体/值对象	事务边界说明
DAG编排	DagDefinition	Node（实体）、Edge（值对象）、DagVersion（值对象）	一个DAG定义及其所有节点、边必须在同一个事务中保存
任务调度	SchedulePlan	Trigger（实体）、ScheduleRule（值对象）、ExecutionWindow（值对象）	调度计划的创建与触发规则变更需保持原子性
任务执行	TaskInstance	ExecutionLog（实体）、RetryRecord（值对象）、ResourceUsage（值对象）	单个任务实例的状态变更（如运行→成功/失败）必须原子化

4.3.2 实体与值对象的区分原则

在DDD中，实体拥有唯一标识符且其状态会随时间变化；值对象则通过属性值来定义，不可变且没有独立标识。在任务调度场景中：

实体示例： TaskInstance（每个实例有唯一ID，状态从PENDING→RUNNING→SUCCESS/FAILED变化）、Worker（有唯一ID，心跳状态动态变化）。
值对象示例： DagEdge（由上游节点ID和下游节点ID定义，不可变）、CronExpression（由cron字符串定义，无独立标识）、RetryPolicy（由最大重试次数和间隔定义）。

  设计原则： 优先使用值对象而非实体。例如，DagEdge 作为值对象可以避免在数据库中为每条边生成独立ID，简化了DAG版本对比和持久化逻辑。只有当对象需要被独立追踪和修改时，才将其设计为实体。

4.3.3 聚合设计实战：DAG编排上下文

以DAG编排上下文为例，展示聚合根与实体的具体划分：

// 聚合根：DagDefinition
public class DagDefinition {
    private DagId id;                    // 值对象
    private String name;
    private DagVersion currentVersion;   // 值对象
    private List<Node> nodes;            // 实体集合
    private List<DagEdge> edges;         // 值对象集合
    private DagStatus status;            // 枚举值对象

    // 聚合根方法：保证内部一致性
    public void addNode(Node node) { /* 校验节点ID唯一性，添加到集合 */ }
    public void addEdge(DagEdge edge) { /* 校验上下游节点存在，拓扑无环 */ }
    public DagVersion createNewVersion() { /* 生成新版本号，冻结当前拓扑 */ }
}

// 实体：Node
public class Node {
    private NodeId id;                   // 实体标识
    private String taskType;
    private Map<String, String> config;  // 值对象
    private NodeStatus status;           // 枚举值对象
}

// 值对象：DagEdge
public class DagEdge {
    private NodeId upstreamNodeId;
    private NodeId downstreamNodeId;
    private EdgeCondition condition;     // 枚举值对象
}

常见误区： 不要将数据库表结构直接映射为聚合。例如，不要因为数据库中有 dag_edge 表就将其设计为实体。在DDD中，DagEdge 作为值对象更合适，因为它的唯一性由两端节点ID决定，且通常不会独立于DagDefinition被修改。

4.4 服务边界划分的DDD实践步骤

在任务调度DAG系统中，按照以下步骤进行服务边界划分：

事件风暴（Event Storming）：与领域专家一起，识别系统中的领域事件（如“DAG创建完成”、“任务执行超时”），通过事件流发现核心领域概念。
识别限界上下文：根据事件分组和业务语义的耦合度，划定上下文边界。例如，所有与“DAG结构定义”相关的事件归入DAG编排上下文。
定义聚合根：在每个上下文中，识别出需要保证事务一致性的聚合边界。通常，一个聚合根对应一个业务原子操作单元。
设计上下文映射：明确上下文之间的通信方式（同步API、异步消息、事件总线），并定义防腐层策略以隔离外部变化。
验证与迭代：通过代码评审和架构测试，验证聚合边界是否合理，避免出现跨聚合的事务或过大的聚合导致性能问题。

经验法则： 如果一个操作需要同时修改两个聚合根，说明聚合边界划分可能不合理，或者应该通过领域事件实现最终一致性。例如，当DAG定义变更时，DAG编排上下文发布 DagChangedEvent，任务调度上下文异步更新调度计划，而非通过分布式事务强一致。

通过DDD的战略设计与战术设计，任务调度DAG系统的服务边界将变得清晰且富有弹性。每个微服务对应一个限界上下文，拥有独立的数据库模式、部署单元和演进节奏，从而支撑大规模任务调度场景下的持续交付与运维。