【架构实战】领域驱动设计DDD：复杂业务系统的建模与落地

【架构实战】领域驱动设计DDD：复杂业务系统的建模与落地

一、背景：一个订单状态引发的血案

2019年底，我们接了一个保险理赔系统。需求文档300页，理赔流程涉及报案、查勘、定损、核赔、支付、结案六个环节，每个环节又有十几种状态和分支条件。

团队按传统三层架构（Controller-Service-DAO）开始写代码。三个月后，代码仓库里出现了一个8000行的ClaimService.java，5000行的PolicyService.java，以及满天飞的if-else。

某天测试提了一个Bug：“拒赔后又赔了”。排查了一天，发现是某个状态机逻辑被绕过去了——因为业务规则散落在五个Service里，没有人能说清楚完整的状态流转。

这就是贫血模型的典型症状：

• 业务逻辑散落在各个Service中，缺乏统一表达
• 数据模型（Entity）只有getter/setter，沦为纯粹的"数据容器"
• 开发与业务沟通成本高，代码读不懂业务意图
• 改一个需求，动辄影响十几个类

CTO拍板：重构，上DDD。

二、DDD核心概念：从贫血到充血

2.1 什么是DDD

DDD（Domain-Driven Design，领域驱动设计）由Eric Evans在2004年提出，核心理念是：将业务领域的核心逻辑封装在领域模型中，代码结构与业务结构保持一致。

关键转变：

【贫血模型】 Entity（只有 getter/setter） ↓ Service（承载所有业务逻辑,越来越胖） ↓ 数据库（数据存储） 【充血模型（DDD）】 聚合根（Aggregate Root，封装业务规则和行为） ↓ 实体（Entity，有唯一标识和业务行为） ↓ 值对象（Value Object，无标识，不可变） ↓ 领域服务（Domain Service，处理跨聚合的业务逻辑）

2.2 DDD战略设计三件套

实战体会：DDD的D（Design）其实不太重要，真正重要的是前面两个D（Domain-Driven）。通用语言是DDD落地的第一关——业务与开发用同一种语言对话，需求不会在翻译中丢失。

三、落地方案：从战略设计到战术实现

3.1 限界上下文拆分

我们按业务能力拆分了五个限界上下文：

┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ 投保上下文 │ │ 承保上下文 │ │ 理赔上下文 │ │ (Policy) │──▶│(Underwrite) │──▶│ (Claim) │ └─────────────┘ └─────────────┘ └──────┬──────┘ │ ┌─────────────┼─────────────┐ │ │ │ ┌─────▼─────┐ ┌─────▼─────┐ ┌─────▼─────┐ │ 支付上下文 │ │ 风控上下文 │ │ 通知上下文 │ │(Payment) │ │(RiskCtrl) │ │(Notify) │ └───────────┘ └───────────┘ └───────────┘

每个上下文对应一个独立的微服务，有自己的数据库。

3.2 聚合设计：理赔上下文为例

// 聚合根：理赔单@EntitypublicclassClaimimplementsAggregateRoot{privateClaimIdid;// 值对象：理赔单IDprivatePolicyIdpolicyId;// 值对象：关联保单IDprivateClaimAmountamount;// 值对象：理赔金额privateClaimStatusstatus;// 值对象：理赔状态privateList<ClaimDocument>documents;// 实体：理赔材料privateList<ClaimHistory>histories;// 实体：操作历史privateAuditorauditor;// 值对象：审核人// ====== 业务行为（核心） ======/** 提交理赔 */publicvoidsubmit(List<Document>docs){if(this.status!=ClaimStatus.DRAFT){thrownewDomainException("只有草稿状态的理赔单才能提交");}if(docs.isEmpty()){thrownewDomainException("理赔材料不能为空");}this.status=ClaimStatus.SUBMITTED;this.documents=docs.stream().map(ClaimDocument::from).collect(Collectors.toList());this.addHistory("提交理赔申请");}/** 定损 */publicvoidassess(DamageAssessmentassessment){if(this.status!=ClaimStatus.SUBMITTED){thrownewDomainException("只有已提交的理赔单才能定损");}this.amount=assessment.getEstimatedAmount();this.status=ClaimStatus.ASSESSED;this.addHistory("定损完成，预估金额："+assessment.getEstimatedAmount());}/** 核赔通过 */publicvoidapprove(){if(this.status!=ClaimStatus.ASSESSED){thrownewDomainException("只有已定损的理赔单才能核赔");}this.status=ClaimStatus.APPROVED;this.addHistory("核赔通过");}/** 拒赔 */publicvoidreject(Stringreason){if(this.status==ClaimStatus.PAID||this.status==ClaimStatus.CLOSED){thrownewDomainException("已完成或已关闭的理赔单不能拒赔");}this.status=ClaimStatus.REJECTED;this.addHistory("拒赔，原因："+reason);}privatevoidaddHistory(Stringdescription){this.histories.add(newClaimHistory(description,LocalDateTime.now()));}}// 值对象：理赔金额@EmbeddablepublicclassClaimAmount{privateBigDecimalamount;privateCurrencycurrency;publicClaimAmountadd(ClaimAmountother){if(!this.currency.equals(other.currency)){thrownewDomainException("币种不一致，无法相加");}returnnewClaimAmount(this.amount.add(other.amount),this.currency);}// 值对象不提供setter，不可变}

代码对比：

3.3 领域服务与领域事件

// 领域服务：处理跨聚合的理赔支付@ServicepublicclassClaimPaymentService{@AutowiredprivateClaimRepositoryclaimRepository;@AutowiredprivatePaymentGatewaypaymentGateway;// 防腐层接口@AutowiredprivateApplicationEventPublishereventPublisher;/** 支付理赔款 */@TransactionalpublicvoidpayClaim(ClaimIdclaimId){// 1. 加载聚合Claimclaim=claimRepository.findById(claimId).orElseThrow(()->newDomainException("理赔单不存在"));// 2. 调用支付网关（通过防腐层）PaymentResultresult=paymentGateway.pay(newPaymentRequest(claim.getAmount(),claim.getPayee()));// 3. 更新聚合状态claim.markAsPaid(result.getTransactionId());claimRepository.save(claim);// 4. 发布领域事件eventPublisher.publishEvent(newClaimPaidEvent(claim.getId(),claim.getAmount()));}}// 领域事件@GetterpublicclassClaimPaidEventextendsDomainEvent{privatefinalClaimIdclaimId;privatefinalClaimAmountpaidAmount;publicClaimPaidEvent(ClaimIdclaimId,ClaimAmountpaidAmount){super(LocalDateTime.now());this.claimId=claimId;this.paidAmount=paidAmount;}}

3.4 防腐层（Anti-Corruption Layer）

用于隔离外部系统对领域模型的污染：

// 防腐层接口（领域层定义）publicinterfacePaymentGateway{PaymentResultpay(PaymentRequestrequest);}// 防腐层实现（基础设施层）@ComponentpublicclassWechatPaymentGatewayimplementsPaymentGateway{@AutowiredprivateWechatPayClientwechatPayClient;@OverridepublicPaymentResultpay(PaymentRequestrequest){// 将领域对象转换为微信支付的DTOUnifiedOrderRequestwxReq=WechatPayConverter.toWechatRequest(request);// 调用外部APIUnifiedOrderResponsewxResp=wechatPayClient.unifiedOrder(wxReq);// 将外部返回转换为领域对象returnWechatPayConverter.toPaymentResult(wxResp);}}

四、仓库模式与持久化分离

// 仓库接口（领域层）publicinterfaceClaimRepository{Optional<Claim>findById(ClaimIdid);List<Claim>findByPolicyId(PolicyIdpolicyId);voidsave(Claimclaim);voiddelete(ClaimIdid);}// 仓库实现（基础设施层，基于JPA）@RepositorypublicclassJpaClaimRepositoryimplementsClaimRepository{@AutowiredprivateJpaClaimDaoclaimDao;@AutowiredprivateJpaClaimDocumentDaodocumentDao;@Override@Transactionalpublicvoidsave(Claimclaim){// 聚合根+子实体一起持久化ClaimPOclaimPO=ClaimConverter.toPO(claim);claimDao.save(claimPO);// 级联保存理赔材料List<ClaimDocumentPO>docPOs=claim.getDocuments().stream().map(doc->ClaimConverter.toDocumentPO(doc,claim.getId())).collect(Collectors.toList());documentDao.saveAll(docPOs);}}

一个聚合一个仓库，一次事务只修改一个聚合——这是DDD的铁律。

五、DDD落地的四大坑

5.1 坑一：过度设计

症状：项目启动第一周就在画限界上下文、设计聚合、定义值对象，代码没写几行。

解决：先写代码，后建模。迭代式DDD：第一版按照直觉拆分模块，第二版调整聚合边界，第三版引入领域事件。不要追求完美的DDD，先跑起来。

5.2 坑二：聚合边界不清

症状：聚合太大，一次加载几千条数据；聚合太小，到处是跨聚合的事务问题。

解决：小聚合原则——一个事务只修改一个聚合。如果发现一个业务操作需要同时修改两个聚合，检查是否应该把它们合并，或者通过领域事件解耦。

5.3 坑三：通用语言推行不下去

症状：文档里写"理赔单已核赔通过"，代码里写的claim.setStatus(5)，讨论的时候说"状态改成5了"。

解决：用代码约束语言。用枚举代替魔法数字，用值对象包装原始类型，让代码本身就是通用语言的载体。业务人员看不懂代码，但能看懂方法名claim.approve()。

5.4 坑四：DDD面试造火箭，工作拧螺丝

症状：花重金招了DDD架构师，实际业务就两张表CRUD。

解决：不是所有业务都适合DDD。DDD的核心价值是应对复杂业务逻辑。如果业务主要是CRUD，用DDD是杀鸡用牛刀。判断标准：业务流程的if-else超过三层吗？状态机超过10个状态吗？业务规则频繁变化吗？如果三个回答都是"否"，别用DDD。

六、总结

DDD不是银弹，它是一套应对复杂性的建模方法论。

核心收获：

1. 通用语言是第一步：团队先统一术语，DDD才有落地基础
2. 聚合是战术核心：设计好的聚合，DDD成功了一半。遵循"小聚合、一次事务一个聚合"的原则
3. 充血模型让代码会说话：业务规则写在聚合根的方法里，代码即文档
4. 防腐层是架构安全阀：不要让外部系统的数据格式污染你的领域模型
5. 迭代优于一次到位：DDD建模是动态过程，不要追求一步到位

选型建议：

领域驱动设计的本质不是技术，而是让代码反映业务。当你读代码就能理解业务流程的时候，DDD就落地了。

个人观点，仅供参考