从 50 字段订单表到可演进订单领域：一次基于真实代码的 DDD 重构分析

本文基于本人在负责项目订单模块进行分析。目标是尝试分析如果用 DDD 重构在保留现有单体架构的前提下是否能够解决订单模型职责混杂、状态流转分散以及渠道回调幂等边界不清的问题。业务场景一张号卡是如何被交付的在进入代码分析前先说一下项目的业务背景。这个订单模块服务的是号卡产品的线下履约场景用户可能从直播、分销、外部平台或人工录单等渠道进入系统运营人员需要对订单进行外呼、核验和分派配送人员接单后完成上门办理同时系统还要根据产品和地区把订单推送到不同运营商或服务商并接收物流、开卡、首充、失败等后续结果。所以一张订单并不是“用户下单后发货”这么简单它通常会经历下面这条链路订单进入系统外部导入、分销、直播或人工录单运营处理外呼、核验、补充资料履约分派分派配送员或进入抢单大厅渠道执行匹配产品和地区提交运营商上门履约接单、配送、改约或失败结果回传物流、开卡、首充、渠道回调和查单这条链路中的每一个节点都可能修改“订单”外呼会改变触达结果分派会改变人员归属运营商提单会写入外部单号配送会改变履约状态回调又会补充开卡号码、物流和首充信息。项目早期把这些变化统一放进订单模型是很自然的选择开发速度也很快但当渠道、产品、资料要求和人员协作不断增加后“所有东西都更新订单”就开始成为后文要讨论的核心问题。一、问题不是“订单表字段多”而是变化没有边界在多数业务系统中订单都会逐渐变复杂客户资料、地址、产品、配送、来源渠道、外部订单号、审核资料、状态日志、回调结果都会围绕它出现。复杂本身并不可怕真正危险的是这些信息因为“都和订单有关”而不断被塞进同一个实体、同一张表、同一个更新接口。我最初设计的订单模块正处在这个阶段实体本身约有50 个字段并同时承载客户、地址、组织归属、外呼、隐私号、营销、审核和履约状态。与此同时代码中还有 12 个以Order开头的关联模型覆盖订单项、物流、图片、视频、通话、历史、状态日志、来源和公共抢单等能力。这不是简单的“表设计不规范”而是一个更值得讨论的信号订单边界正在被多个业务上下文共同使用但系统还没有明确地表达这些上下文。本文讨论三个问题当前订单模型里混在一起的职责究竟有哪些为什么状态校验、锁和日志都存在状态一致性仍然存在风险是否应该引入 DDD如果应该如何避免一次高风险重构二、从代码还原当前订单模型当前订单主实体不是一个纯粹的“交易订单”而是多个业务阶段的共享载体。把字段按变化原因重新分类可以得到下面这张图。各位大佬如果觉得设计的垃圾请轻点喷喷的同时给出一些意见本人半个科班出身水平一般 ~围绕主表的子模型又包含了更多不同性质的数据现有模型当前承载的主要信息更接近的业务含义OrderItem产品、直播间、物流单号、运营商意向单号、运营商订单号、首充时间商品快照 渠道履约信息OrderExpress物流原始数据物流跟踪OrderImage/OrderVideo合规图片、视频和存储元数据资料与合规OrderCall通话记录客户触达OrderHistory来源、类型、人员和状态快照变更历史OrderStatusLog前后状态、操作者、备注状态审计SysTelecomPushLog/ 查单日志外部请求与结果渠道执行审计这张表格揭示了一个关键事实系统已经在用多个实体表达不同概念只是这些概念尚未以清晰的领域边界组织起来。2.1 一张订单表中混入了四类变化从变更频率和责任归属看至少可以分出四类数据订单事实客户是谁、收货地址是什么、订单来自哪里、何时创建。履约过程谁负责配送、是否接单、是否改约、何时完成。渠道执行向哪个运营商提交、渠道单号是什么、渠道返回什么状态、是否需要重试。资料与审核身份证识别、通话录音、合规图片、订单视频。它们都围绕订单但变化原因不同修改地址不应影响渠道重试补一张合规图不应触发配送状态迁移运营商回调不应直接理解为客户履约完成。如果这些差异只靠 Service 名称和开发者经验维持系统规模一大修改一个字段时就很难判断应该更新主表、订单项、渠道日志还是资料表。三、当前状态机制已有保护但规则没有收口当前订单状态使用整数 待分配、待外呼、待配送、配送中、失败、改约、成功、未接电话和客户号码异常。它覆盖了从外呼到配送再到终态的主线。我在维护系统过程中并非没有治理以下是我做的一些设计与维护人工更新订单时会先读取当前状态并通过订单Validator做角色化的流转校验。抢单和自动分派等场景使用WHERE status 待分配的条件更新避免两个配送员同时抢到同一订单。状态日志通过LogOrderStatus切面记录操作者、原状态和动作信息。外部渠道查单结果应用器会识别本地成功/失败终态避免常规查单重复推进状态。部分渠道推单使用分布式锁降低重复提交风险。这些措施解决了很多实际问题但它们分布在 Controller、Service、任务、回调和切面中。不同入口拥有不同保护强度导致系统的真实状态规则不是一张表而是一组分散的代码约定。3.1 一个status承担了多条生命周期这里我在后面Review代码的时候发现了一个被忽视的问题是当前订单状态字段同时表达了至少三种不同的流程。这是我在后续维护上给我造成了许多困扰生命周期典型状态或动作真正关心的问题客户触达待外呼、未接电话、号码异常客户是否可联系、是否需要再次触达人员分派待分配、待配送、抢单、分派谁拥有履约责任、是否允许抢单配送履约配送中、成功、失败、改约服务是否实际完成、是否需要改约或结束渠道处理推单成功、意向单、回调、查单外部系统是否接受、是否开卡、是否可重试这些流程有关联但并不等价。例如渠道“已受理”通常只能说明外部单已创建不必然代表本地订单已经“配送中”。客户“未接电话”是触达结果未必等价于履约失败。“改约”可能是履约过程中的暂停状态也可能是一个需要重新安排的子流程。渠道开卡成功和配送成功在某些业务中一致在另一些业务中却是两个不同事实。当所有语义都压缩进一个整数状态时后续只能不断添加例外某个角色能否回退、某个渠道能否覆盖、某个任务在什么状态下运行。例外越多状态机越像一套难以完整描述的权限规则而不是领域规则。3.2 现有更新方式仍有并发窗口人工更新入口会先读取订单、校验状态再按订单 ID 执行更新。这能避免很多非法操作但如果两个请求在同一时刻读到相同旧状态它们都可能通过校验除非最终 SQL 再带上旧状态或版本号否则后写入者仍可能覆盖先写入者。渠道路径的风险更明显运营商推单确认成功后会将订单直接更新为“配送中”。这条路径本身合理但如果此时订单已被人工处理为失败、成功或改约延迟到达的渠道结果可能反向覆盖本地更晚的业务事实。外部渠道查单结果应用器已经加入“终态不再更新”的意图这是非常好的方向但要把它升级为真正的并发保障最终更新 SQL 也应携带状态条件或乐观锁版本而不是只根据读取时的对象判断。乐观锁机制我在初学的时候时常作为八股文进行背诵和理解,到我真实实践的时候总觉有必要。3.3 状态日志不能替代状态机状态日志解决的是“发生过什么”状态机解决的是“什么可以发生”。我设计的初衷是因为一件比较头疼的事情就是订单状态流转无法溯源导致定责和恢复困难于是我设计了状态流转表记录每次多方人员操作订单的记录最初就是这么想的没想到后续这个状态流转日志在业务线上帮了我解决很多运营上的问题是我比较惊喜的一个设计和方案。在这个表设计后 因为运营人员频繁错误的操作导致订单被回收批量误操作导致订单状态错乱这个时候我们就通过这张表配合日志TraceId定位进行了批量的恢复但是在恢复数据这种场景依旧没有形成一个好的解决方案还是使用状态日志 写SQL方式回写这也是我想优化的。还有一点是AOP切面日志对人工接口很有效但渠道回调、定时任务、批处理或底层 Wrapper 直接更新不一定会经过同一个注解入口。日志可以作为审计补偿却不应该成为状态规则的唯一承载方式。四、幂等性锁只是其中一层我自己看过很多文章自己也有实践我实践过程中发现订单领域经常把“加锁”和“幂等”混为一谈。锁只解决同一时刻的并发竞争幂等还要解决重复请求、超时重试、消息重放、回调重复和跨天补偿。对于我负责的系统在研发和维护过程中迭代了至少存在四层幂等需求创建幂等相同外部订单号不能重复创建本地订单。渠道提交幂等同一订单向同一渠道不能因为重试产生多张外部单。回调消费幂等同一渠道回调重复到达时只能产生一次业务效果。状态迁移幂等已经成功或失败的订单不应被相同结果再次推进更不应被过期结果回退。这套模型的重点不是多建几张表而是明确每层的唯一键场景建议唯一键外部订单导入来源 外部订单号渠道提单订单号 渠道码 场景码渠道回调渠道码 eventId无 eventId 时使用外部单号 状态 时间窗口状态更新orderId version或orderId expectedStatus批量任务行处理taskId rowNo或业务幂等键五、DDD 是否适合这个系统为什么我想要引入DDD一方面是我觉得系统维护到后面有点混沌,随着AI Coding的时代到来,都用上了智能体编码, 实体很混乱,想着引入DDD是否能解决问题学习研究结论是适合引入 DDD 的建模思想但不适合现在就按“完整 DDD 微服务”推倒重来。当然我相信大佬们可以把这套系统可以重构成DDD,但是我对于DDD缺乏实践层面的经验和技术,只是初步分析,对于DDD我也是停留在纸上谈兵的阶段AI的意见是系统当前最需要的是把“领域规则”从杂糅的更新逻辑中提炼出来而不是引入更多抽象层。最现实的方式是继续使用 Spring Boot、MyBatis、现有数据库和 Controller但按业务边界组织模块并让关键状态规则只有一个入口。5.1 建议的限界上下文上下文应负责什么不应继续负责什么订单客户快照、收货地址、来源、订单基本事实保存所有渠道单号和渠道状态履约分派、抢单、配送、改约、完成/失败组装第三方渠道请求渠道集成提单、查单、回调、重试、渠道订单状态直接绕过订单规则覆盖主状态产品与资源产品、套餐、库存/现量、首充映射决定配送员归属资料与合规图片、视频、OCR、录音和审核结论改写订单履约状态组织与权限代理商、成员、数据范围持有订单生命周期规则5.2 聚合如何划分其实说简单点就是 继续拆分上下文,实体,但是这样会让系统复杂度更高了,梳理起来很头疼AI建议是不要把所有表都塞入一个超大聚合。更适合的拆法是Order订单聚合订单基本事实、当前业务状态、状态版本号只允许通过领域方法改变核心状态。Fulfillment履约聚合或履约模块配送员归属、接单、改约、物流和完成结果。ChannelOrder渠道履约单渠道代码、外部订单号/意向单号、渠道状态、请求幂等键、最后回调时间、失败原因、重试信息。ComplianceAsset合规资料图片、视频、OCR/录音结果与订单关联但独立演进。其中最优先的新模型是ChannelOrder。它可以逐步承接目前散落在Order、OrderItem、推单日志和查单日志里的外部系统状态而不要求一次迁移所有老字段。六、目标状态机从“设置整数”转向“执行命令”状态机的目标不是禁止所有回退而是把回退、人工修正、渠道同步都变成显式业务动作。后台运营/管理员可以有修正权限但它不应等价于可以随意setStatus。完成外呼或无需外呼分派或抢单成功配送员确认接单履约完成履约失败客户改约重新分派原配送员继续履约待外呼待分配待配送配送中改约中已成功已失败目前代码是没有的还是依赖更新方法以至于膨胀到一个方法几百行,过错过错在代码层关键不再是暴露一个可写入任意字段的updateStatus而是建立清晰命令order.assignTo(agent,operator);order.acceptBy(agent,operator);order.startDelivery(operator);order.complete(completionEvidence,operator);order.fail(failureReason,operator);order.reschedule(appointment,operator);每个方法都负责校验当前状态是否允许迁移。校验操作者和归属关系。更新状态、业务时间和必要快照。产生OrderStatusChanged领域事件。通过版本号或旧状态条件保证并发下只有一个迁移成功。渠道回调不再直接执行setStatus(配送中)而是先更新ChannelOrder再根据渠道状态与本地履约状态的映射发起明确命令例如confirmChannelAccepted或completeByChannel。七、渐进式迁移不推倒重来DDD 重构最危险的方式是先画出完美模型再要求一次替换所有表和接口。对正在运行的订单系统这种首先是很危险的其次做完了需要做大量的回归测试验证目前团队人数有限很难做到更可靠的路线是增量迁移。阶段一先统一语言和状态规则建立状态迁移矩阵每个状态允许哪些命令、哪些角色、哪些前置条件。将状态常量升级为枚举或值对象统一状态文本、终态判断和可迁移判断。为人工修改、抢单、分派、渠道回调、定时同步补充状态机测试。阶段二建立统一状态迁移服务保留旧接口但将核心状态修改逐步委托给OrderTransitionService。更新 SQL 增加version或expectedStatus条件。所有成功迁移统一发布领域事件日志从“接口注解附带能力”转为“迁移结果必然产物”。阶段三新增渠道履约单不急于删除旧字段新建channel_order保存渠道、外部单号、渠道状态、请求幂等键、最后结果和版本。新渠道优先使用新表运营商、外部渠道等老渠道先双写并校验一致性。逐步把订单项中渠道专属单号迁移为只读兼容字段。阶段四把查询与写入分开演进写模型遵守领域边界订单、履约、渠道单各自更新。列表和详情可以继续通过 MyBatis 聚合查询必要时建立读模型或视图。不为了“纯 DDD”牺牲现有报表和运营查询效率。阶段五补齐可靠事件与回调基础设施渠道回调引入收件箱去重记录。订单状态事件使用 Outbox 或可靠任务投递。重试基于渠道履约单状态而不是前端重复点击或临时日志判断。八、结语DDD 的价值是把不确定性关进边界里这个订单系统当前最宝贵的地方是已经积累了大量真实业务规则分派保护、角色校验、渠道锁、状态日志、查单补偿、合规资料和资源同步。问题不在于这些规则不存在而在于它们分散在不同技术入口中。因此DDD 在这里的价值不是制造更多类和接口而是回答四个必须清楚的问题这次变化属于订单、履约、渠道还是合规谁可以触发这次变化前置状态是什么重复消息和并发请求到来时哪个结果应该生效变化发生后日志、资源、通知和统计如何可靠地跟随当这些问题都由清晰的模型、命令、状态机和幂等键表达时订单系统才会从“能不断加功能”走向“可以持续演进”。