当前位置：首页 > news >正文

别再空谈DDD了！我用一个真实的客服协同单案例，带你落地领域驱动设计

news 2026/5/27 23:50:29

从理论到实战：用DDD重构客服协同单系统的完整指南

如果你已经读过几本领域驱动设计（DDD）的书籍，参加过几次相关培训，却依然对如何在实际项目中应用它感到迷茫，这篇文章正是为你准备的。我们将通过一个真实的客服协同单系统重构案例，展示如何将DDD的理论转化为可执行的代码结构。

1. 为什么选择客服协同单作为DDD实践案例

客服协同单系统看似简单，实则隐藏着复杂的业务规则和状态流转逻辑。典型的协同单需要处理：

多角色协作：创建、分配、转交、处理、关闭等环节涉及不同岗位人员
复杂状态机：从"待分配"到"已完结"可能经历十余种状态变化
业务规则嵌套：分单策略可能涉及技能组匹配、负载均衡、历史处理记录等维度
审计追踪：需要完整记录每个操作的时间点和操作人

这些特性使得协同单系统成为验证DDD价值的理想场景。当系统发展到一定规模后，传统的贫血模型会导致：

业务逻辑分散在多个Service类中
状态校验代码重复出现在各个方法
新增需求时需要修改多处代码
团队成员对业务概念理解不一致

2. 从需求分析到领域建模

2.1 事件风暴工作坊

我们组织了包含产品经理、领域专家、架构师和核心开发人员的工作坊，使用便签纸进行事件风暴。关键产出包括：

核心事件：
- 协同单已创建
- 协同单已分配
- 协同单已受理
- 协同单已转交
- 协同单已关闭

关键命令：

创建协同单 → 触发 → 协同单已创建 分配协同单 → 触发 → 协同单已分配 受理协同单 → 触发 → 协同单已受理

重要实体：
- 协同单（CoordinationCase）
- 技能组（SkillGroup）
- 操作记录（OperationLog）

2.2 统一语言建立

为避免术语歧义，我们明确定义了关键概念：

术语	定义
协同单	客服处理客户问题的工单，可能关联多个业务单据
技能组	按业务能力划分的客服分组，如"退票组"、"改签组"
分单策略	决定协同单分配给哪个技能组的规则集合
操作记录	记录协同单状态变更的完整轨迹，包括操作人、时间、前/后状态

2.3 限界上下文划分

通过分析业务能力和数据关系，我们识别出三个核心限界上下文：

协同单上下文：
- 负责协同单的生命周期管理
- 包含状态流转、操作记录等核心逻辑
- 与其他上下文通过ID引用而非直接对象关联
技能组上下文：
- 管理客服人员的分组和能力标签
- 提供根据策略获取合适客服的接口
- 独立于协同单进行迭代演进
分单策略上下文：
- 维护各种分单规则及其优先级
- 根据协同单特征匹配最适合的策略
- 输出技能组ID而非具体人员

这种划分确保了各上下文的内聚性，同时通过明确的接口定义降低了耦合度。

3. 战术模式落地实践

3.1 聚合设计

协同单聚合根的设计经历了多次迭代优化：

初始设计：

public class CaseAggregate { private Long id; private String status; private Long assigneeId; // 直接存储客服人员ID private List<OperationLog> logs; // 省略其他字段和方法 }

问题发现：

客服人员信息变更时无法同步更新历史记录
分配逻辑与协同单强耦合
状态校验逻辑分散在各方法中

最终设计：

public class CaseAggregate extends BaseAggregate { private final CaseEntity caseEntity; private final List<CaseRecord> records; public void assign(SkillGroupId groupId, AssignmentStrategy strategy) { // 状态校验 if (!caseEntity.canAssign()) { throw new IllegalStateException("当前状态不允许分配"); } // 调用领域服务获取具体人员 Assignee assignee = assignmentService.getAssignee(groupId, strategy); // 更新内部状态 caseEntity.assignTo(assignee); records.add(CaseRecord.assigned(assignee)); } }

关键改进点：

引入值对象（Assignee、SkillGroupId）替代原始类型
将分配策略委托给专门的领域服务
在聚合内封装状态校验逻辑
操作记录作为独立实体管理

3.2 领域服务设计

分配协同单涉及多个聚合的协作，我们将其放在领域服务中实现：

public class CaseAssignmentServiceImpl implements CaseAssignmentService { private final CaseRepository caseRepository; private final SkillGroupService skillGroupService; @Transactional public void assignCase(Long caseId) { CaseAggregate caseAgg = caseRepository.findById(caseId); CaseType caseType = caseAgg.getType(); // 获取匹配的策略 AssignmentStrategy strategy = strategyService.matchStrategy(caseType); // 获取合适的技能组 SkillGroupId groupId = skillGroupService.resolveGroup(caseType); // 委托聚合根执行分配 caseAgg.assign(groupId, strategy); caseRepository.save(caseAgg); } }

3.3 仓储实现技巧

为保持领域模型的纯净，我们在仓储实现中做了以下处理：

聚合重建：

public class CaseRepositoryImpl implements CaseRepository { @Override public CaseAggregate findById(Long id) { CasePO po = caseMapper.selectById(id); List<RecordPO> recordPos = recordMapper.selectByCaseId(id); // PO转领域对象 CaseEntity entity = CaseConverter.toEntity(po); List<CaseRecord> records = recordPos.stream() .map(CaseConverter::toRecord) .collect(Collectors.toList()); return new CaseAggregate(entity, records); } }

变更追踪：

@Override public void save(CaseAggregate aggregate) { // 仅保存变更过的字段 CaseUpdate update = new CaseUpdate(); if (aggregate.getCaseEntity().isStatusChanged()) { update.setStatus(aggregate.getCaseEntity().getStatus()); } // 其他字段检查... caseMapper.updateSelective(aggregate.getId(), update); }

4. 代码组织结构

最终项目结构体现了清晰的架构分层：

src/ ├── main/ │ ├── java/ │ │ ├── application/ # 应用层 │ │ │ ├── CaseAppService.java │ │ │ └── assemblers/ # DTO转换 │ │ ├── domain/ # 领域层 │ │ │ ├── model/ # 聚合根、实体、值对象 │ │ │ ├── services/ # 领域服务 │ │ │ └── repositories/ # 仓储接口 │ │ └── infrastructure/ # 基础设施层 │ │ ├── persistence/ # 数据库实现 │ │ └── client/ # 外部服务调用 │ └── resources/ │ └── mapping/ # MyBatis映射文件