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

从理论到实战用DDD重构客服协同单系统的完整指南如果你已经读过几本领域驱动设计DDD的书籍参加过几次相关培训却依然对如何在实际项目中应用它感到迷茫这篇文章正是为你准备的。我们将通过一个真实的客服协同单系统重构案例展示如何将DDD的理论转化为可执行的代码结构。1. 为什么选择客服协同单作为DDD实践案例客服协同单系统看似简单实则隐藏着复杂的业务规则和状态流转逻辑。典型的协同单需要处理多角色协作创建、分配、转交、处理、关闭等环节涉及不同岗位人员复杂状态机从待分配到已完结可能经历十余种状态变化业务规则嵌套分单策略可能涉及技能组匹配、负载均衡、历史处理记录等维度审计追踪需要完整记录每个操作的时间点和操作人这些特性使得协同单系统成为验证DDD价值的理想场景。当系统发展到一定规模后传统的贫血模型会导致业务逻辑分散在多个Service类中状态校验代码重复出现在各个方法新增需求时需要修改多处代码团队成员对业务概念理解不一致2. 从需求分析到领域建模2.1 事件风暴工作坊我们组织了包含产品经理、领域专家、架构师和核心开发人员的工作坊使用便签纸进行事件风暴。关键产出包括核心事件协同单已创建协同单已分配协同单已受理协同单已转交协同单已关闭关键命令创建协同单 → 触发 → 协同单已创建 分配协同单 → 触发 → 协同单已分配 受理协同单 → 触发 → 协同单已受理重要实体协同单CoordinationCase技能组SkillGroup操作记录OperationLog2.2 统一语言建立为避免术语歧义我们明确定义了关键概念术语定义协同单客服处理客户问题的工单可能关联多个业务单据技能组按业务能力划分的客服分组如退票组、改签组分单策略决定协同单分配给哪个技能组的规则集合操作记录记录协同单状态变更的完整轨迹包括操作人、时间、前/后状态2.3 限界上下文划分通过分析业务能力和数据关系我们识别出三个核心限界上下文协同单上下文负责协同单的生命周期管理包含状态流转、操作记录等核心逻辑与其他上下文通过ID引用而非直接对象关联技能组上下文管理客服人员的分组和能力标签提供根据策略获取合适客服的接口独立于协同单进行迭代演进分单策略上下文维护各种分单规则及其优先级根据协同单特征匹配最适合的策略输出技能组ID而非具体人员这种划分确保了各上下文的内聚性同时通过明确的接口定义降低了耦合度。3. 战术模式落地实践3.1 聚合设计协同单聚合根的设计经历了多次迭代优化初始设计public class CaseAggregate { private Long id; private String status; private Long assigneeId; // 直接存储客服人员ID private ListOperationLog logs; // 省略其他字段和方法 }问题发现客服人员信息变更时无法同步更新历史记录分配逻辑与协同单强耦合状态校验逻辑分散在各方法中最终设计public class CaseAggregate extends BaseAggregate { private final CaseEntity caseEntity; private final ListCaseRecord 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); ListRecordPO recordPos recordMapper.selectByCaseId(id); // PO转领域对象 CaseEntity entity CaseConverter.toEntity(po); ListCaseRecord 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映射文件5. 实践中的经验教训在半年多的DDD实践中我们总结了以下关键经验小步快跑不要试图一次性建模整个系统从核心流程开始迭代持续重构随着业务理解深入及时调整模型技术债务管理为遗留代码划定边界逐步替换团队培养定期组织领域知识分享会一个典型的演进过程可能是第一阶段实现基本的创建-分配-处理流程第二阶段引入技能组和分单策略第三阶段增加转交和协同处理能力第四阶段优化性能引入事件溯源当系统处理日均10万协同单时这种架构展现了良好的扩展性。新成员能够在两周内理解核心领域逻辑新增需求的平均实现时间缩短了40%。最重要的是产品和技术团队终于能够用同一种语言讨论问题减少了大量的沟通成本。