📚 课程目录第3章领域边界概念

3. 领域边界概念：领域驱动设计(DDD)简介

在构建异步任务系统时，领域驱动设计（Domain-Driven Design, DDD） 提供了一套将业务复杂性映射到软件模型的方法论。DDD 的核心思想是：技术实现应服务于业务领域，而非反过来。对于 DB 与 Redis 的职责划分，DDD 的“领域边界”概念是决定数据归属与一致性的关键依据。

3.1 领域驱动设计核心要素

DDD 通过以下战术模式将业务逻辑封装为可维护的模型：

战术模式	职责	与异步任务的关系
实体（Entity）	具有唯一标识、生命周期可追踪的对象	异步任务处理的目标对象（如订单、用户）
值对象（Value Object）	描述属性，无标识，不可变	任务参数、配置快照
聚合（Aggregate）	一组实体的边界封装，外部只能通过聚合根访问	异步任务的事务边界
领域服务（Domain Service）	处理跨实体或跨聚合的业务逻辑	任务编排、状态机流转
仓储（Repository）	提供聚合的持久化与检索	DB 是主仓储，Redis 是缓存/队列仓储

  关键原则： 聚合内部保证强一致性，聚合之间通过异步消息实现最终一致性。这正是 DB 与 Redis 在异步任务中协作的理论基础。

3.2 领域边界定义

领域边界（Bounded Context） 是 DDD 中最重要的战略设计概念。它明确了每个子领域（Subdomain）的职责范围、数据模型和通信协议。在异步任务场景中，领域边界决定了：

数据主权： 哪些数据属于 DB（持久化、强一致），哪些数据属于 Redis（缓存、队列、临时状态）。
一致性级别： 边界内使用强一致性（DB 事务），边界间使用最终一致性（异步消息）。
任务生命周期： 任务在哪个边界内创建、流转、完成或失败。

实战经验： 将“订单处理”作为一个独立的有界上下文，其内部使用 DB 事务保证订单状态与库存扣减的强一致；而“通知发送”作为另一个上下文，通过 Redis 队列异步消费订单完成事件，允许短暂延迟。

3.3 Redis 与 DB 的职责划分

基于领域边界，我们可以清晰地定义 Redis 和 DB 在异步任务系统中的职责：

维度	DB（关系型/持久化存储）	Redis（内存数据存储）
数据持久性	强持久化，支持 AOF/RDB 恢复	默认内存存储，可配置持久化但非强保证
一致性模型	ACID 事务，强一致性	最终一致性，支持 Lua 脚本实现原子操作
查询能力	复杂 SQL 查询、关联、聚合	基于 Key 的简单查询，支持数据结构操作
典型用途	聚合根持久化、任务记录、审计日志	任务队列、缓存、分布式锁、计数器、临时状态
领域边界角色	主仓储（Source of Truth）	辅助仓储（缓存/队列/临时存储）

常见误区： 不要将 Redis 当作“万能数据库”来存储核心业务聚合。Redis 的持久化机制（RDB/AOF）在极端情况下可能丢失数据，且缺乏关系型数据库的查询与事务能力。核心业务数据必须以 DB 为主，Redis 作为加速或解耦的辅助层。

3.4 异步任务中的职责划分实践

以一个典型的“订单异步处理”流程为例，展示 DB 与 Redis 在领域边界内的协作：

订单创建（订单上下文）： 用户提交订单，DB 事务写入订单聚合（订单表、订单项表、库存扣减）。
任务入队（边界跨越）： 订单创建成功后，将“订单完成事件”写入 Redis 队列（List 或 Stream）。
任务消费（通知上下文）： 通知服务从 Redis 队列拉取事件，生成通知记录并写入 DB。
状态更新（最终一致性）： 通知发送成功后，通过异步回调更新订单上下文中的通知状态（Redis 缓存 + DB 异步更新）。

3.5 领域边界划分的决策矩阵

在实际项目中，可以通过以下问题来判断数据应归属 DB 还是 Redis：

决策问题	DB 优先	Redis 优先
数据丢失是否可接受？	否（核心业务数据）	是（缓存、临时状态）
是否需要复杂查询？	是（SQL 关联、聚合）	否（Key-Value 或简单结构）
是否需要跨聚合事务？	是（ACID 保证）	否（最终一致性即可）
数据访问延迟要求？	毫秒级（可接受）	微秒级（极致性能）
数据生命周期？	长期持久（年/月）	短期临时（秒/分钟/小时）

  总结： 领域边界是 DB 与 Redis 职责划分的“宪法”。在边界内部，DB 负责强一致与持久化；在边界之间，Redis 负责解耦、加速与最终一致性。理解并遵循这一原则，才能构建出既可靠又高性能的异步任务系统。