1. 课程导论：DAG任务调度在微服务架构中的位置、为什么需要关注服务边界与限界上下文
1.1 微服务架构中的DAG任务调度：从单体到分布式
在单体架构时代，任务调度通常是一个内嵌的cron表达式或一个简单的线程池。进入微服务架构后，业务逻辑被拆分为多个独立的服务，原本线性的任务流演变为复杂的、跨服务的依赖关系。DAG（有向无环图）任务调度因此成为微服务编排的核心模式。
DAG任务调度在微服务架构中的典型位置如下图所示：
核心定位： DAG调度服务位于业务服务层与基础设施层之间，作为编排中枢，负责解析任务依赖、触发执行、收集状态并处理失败重试。
1.2 为什么需要关注服务边界与限界上下文
在微服务架构中，DAG任务调度面临一个核心矛盾：任务依赖的全局性与服务边界的独立性。如果不加约束地让调度服务直接感知所有服务的内部细节，将导致以下问题：
| 问题 | 表现 | 后果 |
|---|---|---|
| 紧耦合 | 调度服务直接调用业务服务的数据库或内部API | 业务服务变更导致调度频繁修改 |
| 边界模糊 | 任务定义中混入多个领域的逻辑 | 职责不清，难以维护和测试 |
| 数据一致性 | 跨服务事务缺乏明确的边界控制 | 分布式事务失败后难以回滚 |
| 可观测性差 | 任务状态散落在多个服务中 | 排查问题需要跨服务追踪 |
架构警示： 忽视服务边界，DAG调度服务会退化为“分布式单体”——表面上服务化了，实际上仍然是一个紧耦合的调度大泥球。
1.3 限界上下文：为DAG调度划定“势力范围”
领域驱动设计（DDD）中的限界上下文（Bounded Context）为DAG任务调度提供了清晰的边界划分依据。每个限界上下文拥有独立的领域模型、数据存储和业务规则，上下文之间通过上下文映射（Context Map）进行协作。
在DAG调度场景中，典型的限界上下文划分如下：
1.4 课程核心收益
通过本课程，你将掌握：
- 如何识别DAG调度中的限界上下文——从业务需求出发，划分清晰的领域边界。
- 如何设计上下文之间的映射关系——使用事件、API网关、消息队列等模式进行协作。
- 如何避免常见的边界陷阱——如“共享数据库”、“万能调度服务”、“状态耦合”等反模式。
- 如何落地可扩展的DAG调度架构——结合DDD战术模式（聚合、实体、值对象、领域事件）实现调度服务。
学习建议： 本章是后续所有章节的基础。建议在阅读后续内容前，先梳理你当前项目中DAG调度涉及的服务和依赖关系，尝试画出初步的限界上下文草图。