SpringBootFlowable 业务单据状态设计审批、执行与作废为什么不能共用一个 status一张借用单显示“已通过”资产管理员却说设备还没有归还另一张采购单也显示“已通过”仓库却只收到一半。两个页面都没有错问题在于“通过”只回答了审批结果却被用户理解成业务已经结束。当一个 status 同时承担审批、履行和有效性越完整的企业业务越容易被迫增加含义模糊的状态。▲ 状态矩阵是“先审批、后执行”业务的示例不是所有模块的统一规则。审批、执行和有效性共同决定能做什么不必被塞进一条线性状态链。一、状态设计首先是业务语言设计状态是对某个业务问题的简洁回答。审批状态回答“是否获得授权”执行进度回答“已经履行多少”有效性回答“这张单据还能否继续使用”。它们可能有关联但不是同一个问题。例如借用申请通过后资产可以进入使用状态但借用关系仍然持续到归还采购订单通过后可以分多次入库报销申请通过后也未必已经完成付款。把这些记录统一标成“完成”会让列表简洁却让业务失去重要信息。真正需要统一的是状态的定义和操作语义而不是强迫所有业务共用一套数字枚举。一个框架可以统一流程状态但不能因此把资产、库存、付款和人事变更都视为相同的履行过程。维度需要回答的问题常见表现审批当前授权决定是什么未提交、审批中、通过、拒绝履行业务已经执行到什么程度未执行、部分执行、完成或待归还、已归还有效性是否允许继续产生新业务有效、关闭、作废等业务定义并发版本用户依据的数据是否还是当前版本revision、更新时间或其他冲突依据最后一项并不是业务状态却会影响状态变更是否安全。两个人同时看到“待归还”不能仅靠页面上的同一个绿色标签保证他们不会创建重复归还业务。也不必给每张表机械增加四个字段。若执行进度能够从已生效的明细事实准确汇总可以不重复保存若为了查询性能保留汇总字段就要明确它是可重建的投影而不是与明细各自维护的第二份事实。二、借用、归还与资产卡片分别在描述什么1. 借用单获批表示授权与占用已经发生在 RuoYi Office 的资产实现里业务流程回调会更新processStatus。借用单审批通过后服务继续处理资产占用并将借用单的returnStatus设置为待归还。这里已经存在两个不同的状态维度。▲ 真实借用详情页面。页面上的流程结果与业务履行不能混为一谈借用获批并不表示资产已经归还。这是一个很好的业务边界对当前资产借用实现审批通过可以直接触发资产占用不需要凭空再发明一个“待发放”状态但整个借用关系的结束仍然需要归还业务。建模应忠于已有产品动作而不是为了讲状态机而增加用户根本不会操作的步骤。2. 归还是一笔新的业务不是把借用单改回草稿归还单通过sourceAllocateId关联来源借用单。提交时要校验来源是否是借用业务、是否已经通过、是否已归还以及是否已有正在处理的归还申请。▲ 真实归还详情页面。该历史样本的来源借用单字段为空因此这里只展示归还页面结构不把它当作来源校验已通过的证据下文关联约束以当前源码为准。这样保留了两个不同事实某日批准借出另一日批准归还。若只把原单状态从“使用中”改成“空闲”查询当时为什么借出、何时归还、由谁确认时就会缺少业务证据。同样的思想可以推广到退货、退款、冲销和调拨但不能直接复用“归还”的枚举。每一种反向业务都有自己的数量、时间和授权条件所谓通用框架应该帮助保留这些差别而不是消灭它们。3. 资产卡片反映当前结果单据记录形成结果的过程归还审批通过后当前实现会释放资产卡片上的使用信息并回写来源借用单的归还状态和日期。卡片、借用单、归还单各有职责不能把其中任意一个的状态当作全部事实。▲ 真实资产卡片页面用来查看当前结果。此处卡片与前两张单据并非同一资产只用于说明页面职责不作为同一次借还联调的证明。需要注意“当前结果”通常是不断变化的。如果设备之后再次借出卡片会显示新的使用情况历史借用单仍然应保留当时的业务依据。用当前卡片替代历史单据会让过去的记录跟着现在一起变化。三、先定义合法组合再定义按钮和迁移多维状态并不是任意组合。以“必须审批后执行”的业务为例审批中且已经执行完成通常不应出现已通过且未执行则可能是完全正常的待处理状态。但对于审批本身就触发执行的业务某些中间组合可能只有瞬时意义根本不需要展示给用户。因此应先列出业务不变量再决定状态字段。例如“未获授权不得占用资产”“已归还的借用关系不得再次归还”“来源业务不匹配不得回写”“失效单据不得继续增加执行事实”。这些规则比一张画得漂亮的状态流转图更有约束力。操作意图典型前置条件形成的事实提交借用必填完整、资产可借、单据可提交新的流程实例或审批请求审批通过回调属于当前单据和流程授权结果及对应资产占用发起归还来源已通过、尚未归还、无在途重复申请独立归还单据归还通过来源与资产关系仍然有效释放占用并回写来源履行结果关闭或作废符合该业务的失效条件保留原事实限制后续动作不要先把“撤回、取消、作废、冲正”都画成一根指向草稿的箭头。撤回通常针对审批过程取消针对尚未履行的业务意图作废意味着原凭证不再作为后续依据冲正则通过新的事实抵消既有影响。这些词在企业里可能有不同约定产品必须给出自己的定义。已经产生库存、占用或资金影响后直接恢复草稿尤其危险。页面看似回到了起点相关系统却未必恢复。正确方式是先判断能否执行相应反向业务以及反向业务是否需要新的审批和记录。四、让每一次状态变化都能找到业务证据一个可维护的设计会把主单、执行事实、流程关联与操作记录分开。主单适合提供当前概览执行事实说明发生了什么流程实例说明授权如何形成审计记录说明是谁用什么命令改变了系统。▲ 通用设计示意。当前资产模块的 processStatus、returnStatus、sourceAllocateId 提供实际参照图中的统一命令记录和事件体系属于扩展设计。如果业务支持部分执行不建议只保存一个PARTIAL状态。还需要可计算的数量或金额依据。例如申请十件、实际执行六件、撤销一件剩余量如何计算必须有明细支持。状态只是对这些事实的归纳不是替代事实的字符串。对不支持部分归还的现有模块也不能在文章里因为图中出现“部分执行”就宣称已经支持分批归还。是否允许、如何关联明细和校验数量都需要额外设计和实现。抽象模型可以覆盖更广场景但产品能力必须逐项核实。流程回调先确认“我在处理哪张单”下面保留当前资产回调的主要逻辑。它先查询业务单据再校验流程业务类型最后更新审批状态并处理获批动作与这些逻辑无关的注解和周边代码已省略。Transactional(rollbackForException.class)publicvoidupdateProcessStatusForFlow(AssetBillTypeEnumflowBillType,StringbusinessKey,Integerstatus){LongidLong.parseLong(businessKey);AssetAllocateDOexistallocateMapper.selectById(id);if(existnull){throwexception(ASSET_ALLOCATE_NOT_EXISTS);}assertFlowMatchesBill(flowBillType,exist);allocateMapper.updateById(newAssetAllocateDO().setId(id).setProcessStatus(status));if(BpmProcessInstanceStatusEnum.APPROVE.getStatus().equals(status)){onAllocateApproved(exist,flowBillType);}}这段实现证明了审批状态与业务动作的连接点但不能仅凭Transactional就断言具备跨系统恰好一次处理、乱序回调防护或完整事件去重。若业务允许撤回重提、重新发起流程还应明确回调是否属于当前绑定的流程实例。旧流程的迟到消息不能覆盖新流程的结果。更稳妥的扩展是让回调同时携带流程实例标识、业务关联和事件身份在受控事务中检查匹配关系。无法确认归属的消息进入异常记录而不是猜测应该作用于当前单据。来源校验比“按钮只显示一次”更可靠当前归还提交逻辑已经把来源业务与归还进度放到服务端校验。以下按源码整理关键分支保留业务错误语义。privatevoidvalidateReturnSource(AssetAllocateSaveReqVOrequest){LongsourceIdrequest.getSourceAllocateId();if(sourceIdnull)return;AssetAllocateDOsourceallocateMapper.selectById(sourceId);if(sourcenull||!Integer.valueOf(ALLOCATE_TYPE_BORROW).equals(source.getAllocateType())){throwexception(ASSET_ALLOCATE_RETURN_SOURCE_INVALID);}if(!BpmProcessInstanceStatusEnum.APPROVE.getStatus().equals(source.getProcessStatus())){throwexception(ASSET_ALLOCATE_BORROW_NOT_APPROVED);}if(Integer.valueOf(RETURN_STATUS_RETURNED).equals(source.getReturnStatus())){throwexception(ASSET_ALLOCATE_ALREADY_RETURNED);}assertNoActiveReturn(sourceId,request.getId());}真实方法还会校验资产使用情况和公司范围不能在落地时遗漏。查询到“没有在途归还”只是规则判断的一部分若要在高并发下严格防止两个请求同时通过还需要锁定同一来源资源或使用其他数据库原子约束。文章不把先查后写描述为天然并发安全。五、并发问题要按命令处理而不是按页面处理用户打开页面之后状态可能已经被别人改变。前端隐藏按钮可以减少误操作但不能保证提交时的事实仍然相同。服务端必须在执行命令时重新检查状态、权限和数据版本。▲ 建议时序命令记录、状态和执行事实一起提交外部消费者按事件标识处理。Outbox 等事务事件机制是增强方案不代表所有现有模块都已采用。下面是并发命令的设计伪代码。仓储接口代表数据库事务能力前提是命令标识具有租户内唯一约束版本更新是原子操作冲突时会回滚本次事务。Transactional(rollbackForException.class)publicResultexecute(Commandcommand,Subjectsubject){Resultpreviouscommands.findMatchingResult(subject.tenantId(),command.id(),command.payloadDigest());if(previous!null)returnprevious;Billbillbills.lockForUpdate(subject.tenantId(),command.billId());permission.requireOperate(subject,bill,command.action());if(bill.revision()!command.expectedRevision()){thrownewStateConflictException(业务已变化请刷新后确认);}rules.requireAllowed(bill,command);ExecutionfactexecutionFactory.create(bill,command);executions.insert(fact);bills.applyTransition(bill,fact);ResultresultResult.from(fact);commands.saveUnique(command,subject,result);outbox.append(BusinessEvent.from(fact));returnresult;}这里的幂等不是“重复请求直接返回成功”。同一个命令标识携带不同参数时应报冲突同一个业务对象上的不同合法操作也不能被误判成重复。命令身份、业务身份和执行事实身份分别承担不同职责。事务事件还应防止“数据库提交了通知却丢了”。使用 Outbox 等方式时先把待发送事件与业务事实一起保存再由独立投递器重试。消费者仍然需要去重因为投递成功但确认丢失时可能再次收到消息。如果业务动作涉及外部设备、第三方接口或另一个数据库单个本地事务不能把它们全部包住。此时可以设计“处理中、待核实、需要补偿”等明确的处理状态但这些是操作执行状态不应随手污染业务审批枚举。六、前端应该展示业务语言而不是暴露状态码组合后端可以把可执行操作作为结果的一部分返回例如允许查看、编辑、提交或发起归还并带上不允许操作的原因。前端仍应遵守权限体系但不需要在多个页面复制几十组状态判断。显示上也应保留维度。借用单可以同时展示“审批通过”和“待归还”而不是合成一个含义模糊的“处理中”。列表需要简洁时可以选一个业务主状态再在详情说明构成它的事实关键是始终保持定义一致。错误提示要告诉用户如何继续。“状态异常”几乎没有帮助“该借用单已存在审批中的归还申请请查看原申请”则能引导用户处理重复业务。对于并发冲突返回最新状态和关联单号通常比要求用户反复点击更有效。但是可执行操作列表只能作为交互提示不能作为授权令牌。攻击者可以跳过页面直接发请求旧页面也可能携带过期操作。最终校验必须留在服务端的命令处理入口。七、怎样验证状态模型没有隐藏矛盾状态模型应围绕不变量测试而不只测试“从 A 走到 B”。同一条业务路径的重复、逆序、部分失败与并发往往比正常路径更容易暴露设计问题。测试场景要守住的不变量预期结果同一回调重复到达不能重复制造执行影响识别已处理事实或安全重放旧流程回调晚到不覆盖新实例状态拒绝或记录为过期事件两个归还申请同时提交来源关系不能重复结束按原子约束只接受合法请求页面打开后别人已操作不按旧状态继续写入返回冲突并提示刷新外部动作结果不明不伪造业务成功保留待核实状态与证据作废已有履行的单据不抹掉已经发生的事实要求明确反向操作或拒绝数据修复也需要同样的纪律。直接修改状态字段也许能让按钮重新出现却可能破坏台账、数量和流程之间的关系。管理后台若提供纠错入口应要求说明原因、列出影响对象并通过专用业务操作完成而不是对所有人暴露“任意改状态”。对于历史数据可以定期检查不变量例如已归还来源单是否有对应有效归还记录、在用资产是否有可解释的占用来源。发现差异时应先区分展示汇总滞后和真正业务缺失再选择重建投影或补充纠错记录。八、现有工程怎样渐进改造第一步不是引入一个复杂状态机框架而是给当前状态字段写清定义。把“审批状态”和“业务进度”混用的地方标出来确认每个操作真正产生的业务事实。第二步把散落在 Controller、页面和回调里的关键规则集中到业务服务保留已有权限与租户边界。对于资产借用归还可以先围绕来源单、在途归还和卡片占用建立测试。第三步补齐并发与历史证据识别命令、绑定流程实例、限定迁移、记录反向业务。并不要求每个模块马上引入事件总线但不能让网络重试和人工纠错继续依赖运气。第四步才考虑抽象共用组件。可以统一操作日志、冲突提示和命令执行骨架但“什么算完成、什么情况下可以取消”必须留给业务定义。过早统一枚举往往只是把不同模块的复杂性压进一个越来越长的 switch。体验时可按资产借用单、归还单、资产卡片三个入口查看真实行为。本文状态矩阵用于解释通用设计资产实现以实际的借用和归还语义为准不把未实现的部分执行或通用补偿引擎当作已有功能。常见问题一个状态字段一定是错误设计吗不是。简单、严格线性的业务可以只有一个状态。问题是把互相独立、会同时存在的业务事实塞进同一字段导致组合越来越难解释。审批通过后是否应该统一进入“待执行”不应一刀切。有的业务在审批回调中就完成主数据变更或资产占用有的还需要仓库、财务等角色继续执行。状态应对应真实动作不为了形式完整增加无用步骤。有了数据库事务是否还需要幂等需要。本地事务保证一次执行内部的提交关系不自动识别两次请求是不是同一业务意图也不保证跨系统消息只投递一次。作废单据可以物理删除吗是否允许删除由业务留存与审计要求决定。已经形成履行事实的单据通常需要保留可解释的来源和反向记录不能只因为界面想隐藏就删除支撑台账的证据。结语一个可维护的企业系统不是状态枚举最多的系统而是每个状态都能回答明确问题、每个动作都能找到业务证据的系统。审批、履行和有效性分清之后前端更容易解释后端更容易校验发生异常时也更容易恢复。RuoYi Office 的资产借用归还和流程回调提供了实际业务基础。在这些事实之上逐步补齐命令、并发与历史治理比把所有问题交给一个 status 字段更接近企业系统长期运行的真实需要。如果这篇对你有用点个「在看」或收藏。
SpringBootFlowable 业务单据状态设计审批、执行与作废为什么不能共用一个 status一张借用单显示“已通过”资产管理员却说设备还没有归还另一张采购单也显示“已通过”仓库却只收到一半。两个页面都没有错问题在于“通过”只回答了审批结果却被用户理解成业务已经结束。当一个 status 同时承担审批、履行和有效性越完整的企业业务越容易被迫增加含义模糊的状态。▲ 状态矩阵是“先审批、后执行”业务的示例不是所有模块的统一规则。审批、执行和有效性共同决定能做什么不必被塞进一条线性状态链。一、状态设计首先是业务语言设计状态是对某个业务问题的简洁回答。审批状态回答“是否获得授权”执行进度回答“已经履行多少”有效性回答“这张单据还能否继续使用”。它们可能有关联但不是同一个问题。例如借用申请通过后资产可以进入使用状态但借用关系仍然持续到归还采购订单通过后可以分多次入库报销申请通过后也未必已经完成付款。把这些记录统一标成“完成”会让列表简洁却让业务失去重要信息。真正需要统一的是状态的定义和操作语义而不是强迫所有业务共用一套数字枚举。一个框架可以统一流程状态但不能因此把资产、库存、付款和人事变更都视为相同的履行过程。维度需要回答的问题常见表现审批当前授权决定是什么未提交、审批中、通过、拒绝履行业务已经执行到什么程度未执行、部分执行、完成或待归还、已归还有效性是否允许继续产生新业务有效、关闭、作废等业务定义并发版本用户依据的数据是否还是当前版本revision、更新时间或其他冲突依据最后一项并不是业务状态却会影响状态变更是否安全。两个人同时看到“待归还”不能仅靠页面上的同一个绿色标签保证他们不会创建重复归还业务。也不必给每张表机械增加四个字段。若执行进度能够从已生效的明细事实准确汇总可以不重复保存若为了查询性能保留汇总字段就要明确它是可重建的投影而不是与明细各自维护的第二份事实。二、借用、归还与资产卡片分别在描述什么1. 借用单获批表示授权与占用已经发生在 RuoYi Office 的资产实现里业务流程回调会更新processStatus。借用单审批通过后服务继续处理资产占用并将借用单的returnStatus设置为待归还。这里已经存在两个不同的状态维度。▲ 真实借用详情页面。页面上的流程结果与业务履行不能混为一谈借用获批并不表示资产已经归还。这是一个很好的业务边界对当前资产借用实现审批通过可以直接触发资产占用不需要凭空再发明一个“待发放”状态但整个借用关系的结束仍然需要归还业务。建模应忠于已有产品动作而不是为了讲状态机而增加用户根本不会操作的步骤。2. 归还是一笔新的业务不是把借用单改回草稿归还单通过sourceAllocateId关联来源借用单。提交时要校验来源是否是借用业务、是否已经通过、是否已归还以及是否已有正在处理的归还申请。▲ 真实归还详情页面。该历史样本的来源借用单字段为空因此这里只展示归还页面结构不把它当作来源校验已通过的证据下文关联约束以当前源码为准。这样保留了两个不同事实某日批准借出另一日批准归还。若只把原单状态从“使用中”改成“空闲”查询当时为什么借出、何时归还、由谁确认时就会缺少业务证据。同样的思想可以推广到退货、退款、冲销和调拨但不能直接复用“归还”的枚举。每一种反向业务都有自己的数量、时间和授权条件所谓通用框架应该帮助保留这些差别而不是消灭它们。3. 资产卡片反映当前结果单据记录形成结果的过程归还审批通过后当前实现会释放资产卡片上的使用信息并回写来源借用单的归还状态和日期。卡片、借用单、归还单各有职责不能把其中任意一个的状态当作全部事实。▲ 真实资产卡片页面用来查看当前结果。此处卡片与前两张单据并非同一资产只用于说明页面职责不作为同一次借还联调的证明。需要注意“当前结果”通常是不断变化的。如果设备之后再次借出卡片会显示新的使用情况历史借用单仍然应保留当时的业务依据。用当前卡片替代历史单据会让过去的记录跟着现在一起变化。三、先定义合法组合再定义按钮和迁移多维状态并不是任意组合。以“必须审批后执行”的业务为例审批中且已经执行完成通常不应出现已通过且未执行则可能是完全正常的待处理状态。但对于审批本身就触发执行的业务某些中间组合可能只有瞬时意义根本不需要展示给用户。因此应先列出业务不变量再决定状态字段。例如“未获授权不得占用资产”“已归还的借用关系不得再次归还”“来源业务不匹配不得回写”“失效单据不得继续增加执行事实”。这些规则比一张画得漂亮的状态流转图更有约束力。操作意图典型前置条件形成的事实提交借用必填完整、资产可借、单据可提交新的流程实例或审批请求审批通过回调属于当前单据和流程授权结果及对应资产占用发起归还来源已通过、尚未归还、无在途重复申请独立归还单据归还通过来源与资产关系仍然有效释放占用并回写来源履行结果关闭或作废符合该业务的失效条件保留原事实限制后续动作不要先把“撤回、取消、作废、冲正”都画成一根指向草稿的箭头。撤回通常针对审批过程取消针对尚未履行的业务意图作废意味着原凭证不再作为后续依据冲正则通过新的事实抵消既有影响。这些词在企业里可能有不同约定产品必须给出自己的定义。已经产生库存、占用或资金影响后直接恢复草稿尤其危险。页面看似回到了起点相关系统却未必恢复。正确方式是先判断能否执行相应反向业务以及反向业务是否需要新的审批和记录。四、让每一次状态变化都能找到业务证据一个可维护的设计会把主单、执行事实、流程关联与操作记录分开。主单适合提供当前概览执行事实说明发生了什么流程实例说明授权如何形成审计记录说明是谁用什么命令改变了系统。▲ 通用设计示意。当前资产模块的 processStatus、returnStatus、sourceAllocateId 提供实际参照图中的统一命令记录和事件体系属于扩展设计。如果业务支持部分执行不建议只保存一个PARTIAL状态。还需要可计算的数量或金额依据。例如申请十件、实际执行六件、撤销一件剩余量如何计算必须有明细支持。状态只是对这些事实的归纳不是替代事实的字符串。对不支持部分归还的现有模块也不能在文章里因为图中出现“部分执行”就宣称已经支持分批归还。是否允许、如何关联明细和校验数量都需要额外设计和实现。抽象模型可以覆盖更广场景但产品能力必须逐项核实。流程回调先确认“我在处理哪张单”下面保留当前资产回调的主要逻辑。它先查询业务单据再校验流程业务类型最后更新审批状态并处理获批动作与这些逻辑无关的注解和周边代码已省略。Transactional(rollbackForException.class)publicvoidupdateProcessStatusForFlow(AssetBillTypeEnumflowBillType,StringbusinessKey,Integerstatus){LongidLong.parseLong(businessKey);AssetAllocateDOexistallocateMapper.selectById(id);if(existnull){throwexception(ASSET_ALLOCATE_NOT_EXISTS);}assertFlowMatchesBill(flowBillType,exist);allocateMapper.updateById(newAssetAllocateDO().setId(id).setProcessStatus(status));if(BpmProcessInstanceStatusEnum.APPROVE.getStatus().equals(status)){onAllocateApproved(exist,flowBillType);}}这段实现证明了审批状态与业务动作的连接点但不能仅凭Transactional就断言具备跨系统恰好一次处理、乱序回调防护或完整事件去重。若业务允许撤回重提、重新发起流程还应明确回调是否属于当前绑定的流程实例。旧流程的迟到消息不能覆盖新流程的结果。更稳妥的扩展是让回调同时携带流程实例标识、业务关联和事件身份在受控事务中检查匹配关系。无法确认归属的消息进入异常记录而不是猜测应该作用于当前单据。来源校验比“按钮只显示一次”更可靠当前归还提交逻辑已经把来源业务与归还进度放到服务端校验。以下按源码整理关键分支保留业务错误语义。privatevoidvalidateReturnSource(AssetAllocateSaveReqVOrequest){LongsourceIdrequest.getSourceAllocateId();if(sourceIdnull)return;AssetAllocateDOsourceallocateMapper.selectById(sourceId);if(sourcenull||!Integer.valueOf(ALLOCATE_TYPE_BORROW).equals(source.getAllocateType())){throwexception(ASSET_ALLOCATE_RETURN_SOURCE_INVALID);}if(!BpmProcessInstanceStatusEnum.APPROVE.getStatus().equals(source.getProcessStatus())){throwexception(ASSET_ALLOCATE_BORROW_NOT_APPROVED);}if(Integer.valueOf(RETURN_STATUS_RETURNED).equals(source.getReturnStatus())){throwexception(ASSET_ALLOCATE_ALREADY_RETURNED);}assertNoActiveReturn(sourceId,request.getId());}真实方法还会校验资产使用情况和公司范围不能在落地时遗漏。查询到“没有在途归还”只是规则判断的一部分若要在高并发下严格防止两个请求同时通过还需要锁定同一来源资源或使用其他数据库原子约束。文章不把先查后写描述为天然并发安全。五、并发问题要按命令处理而不是按页面处理用户打开页面之后状态可能已经被别人改变。前端隐藏按钮可以减少误操作但不能保证提交时的事实仍然相同。服务端必须在执行命令时重新检查状态、权限和数据版本。▲ 建议时序命令记录、状态和执行事实一起提交外部消费者按事件标识处理。Outbox 等事务事件机制是增强方案不代表所有现有模块都已采用。下面是并发命令的设计伪代码。仓储接口代表数据库事务能力前提是命令标识具有租户内唯一约束版本更新是原子操作冲突时会回滚本次事务。Transactional(rollbackForException.class)publicResultexecute(Commandcommand,Subjectsubject){Resultpreviouscommands.findMatchingResult(subject.tenantId(),command.id(),command.payloadDigest());if(previous!null)returnprevious;Billbillbills.lockForUpdate(subject.tenantId(),command.billId());permission.requireOperate(subject,bill,command.action());if(bill.revision()!command.expectedRevision()){thrownewStateConflictException(业务已变化请刷新后确认);}rules.requireAllowed(bill,command);ExecutionfactexecutionFactory.create(bill,command);executions.insert(fact);bills.applyTransition(bill,fact);ResultresultResult.from(fact);commands.saveUnique(command,subject,result);outbox.append(BusinessEvent.from(fact));returnresult;}这里的幂等不是“重复请求直接返回成功”。同一个命令标识携带不同参数时应报冲突同一个业务对象上的不同合法操作也不能被误判成重复。命令身份、业务身份和执行事实身份分别承担不同职责。事务事件还应防止“数据库提交了通知却丢了”。使用 Outbox 等方式时先把待发送事件与业务事实一起保存再由独立投递器重试。消费者仍然需要去重因为投递成功但确认丢失时可能再次收到消息。如果业务动作涉及外部设备、第三方接口或另一个数据库单个本地事务不能把它们全部包住。此时可以设计“处理中、待核实、需要补偿”等明确的处理状态但这些是操作执行状态不应随手污染业务审批枚举。六、前端应该展示业务语言而不是暴露状态码组合后端可以把可执行操作作为结果的一部分返回例如允许查看、编辑、提交或发起归还并带上不允许操作的原因。前端仍应遵守权限体系但不需要在多个页面复制几十组状态判断。显示上也应保留维度。借用单可以同时展示“审批通过”和“待归还”而不是合成一个含义模糊的“处理中”。列表需要简洁时可以选一个业务主状态再在详情说明构成它的事实关键是始终保持定义一致。错误提示要告诉用户如何继续。“状态异常”几乎没有帮助“该借用单已存在审批中的归还申请请查看原申请”则能引导用户处理重复业务。对于并发冲突返回最新状态和关联单号通常比要求用户反复点击更有效。但是可执行操作列表只能作为交互提示不能作为授权令牌。攻击者可以跳过页面直接发请求旧页面也可能携带过期操作。最终校验必须留在服务端的命令处理入口。七、怎样验证状态模型没有隐藏矛盾状态模型应围绕不变量测试而不只测试“从 A 走到 B”。同一条业务路径的重复、逆序、部分失败与并发往往比正常路径更容易暴露设计问题。测试场景要守住的不变量预期结果同一回调重复到达不能重复制造执行影响识别已处理事实或安全重放旧流程回调晚到不覆盖新实例状态拒绝或记录为过期事件两个归还申请同时提交来源关系不能重复结束按原子约束只接受合法请求页面打开后别人已操作不按旧状态继续写入返回冲突并提示刷新外部动作结果不明不伪造业务成功保留待核实状态与证据作废已有履行的单据不抹掉已经发生的事实要求明确反向操作或拒绝数据修复也需要同样的纪律。直接修改状态字段也许能让按钮重新出现却可能破坏台账、数量和流程之间的关系。管理后台若提供纠错入口应要求说明原因、列出影响对象并通过专用业务操作完成而不是对所有人暴露“任意改状态”。对于历史数据可以定期检查不变量例如已归还来源单是否有对应有效归还记录、在用资产是否有可解释的占用来源。发现差异时应先区分展示汇总滞后和真正业务缺失再选择重建投影或补充纠错记录。八、现有工程怎样渐进改造第一步不是引入一个复杂状态机框架而是给当前状态字段写清定义。把“审批状态”和“业务进度”混用的地方标出来确认每个操作真正产生的业务事实。第二步把散落在 Controller、页面和回调里的关键规则集中到业务服务保留已有权限与租户边界。对于资产借用归还可以先围绕来源单、在途归还和卡片占用建立测试。第三步补齐并发与历史证据识别命令、绑定流程实例、限定迁移、记录反向业务。并不要求每个模块马上引入事件总线但不能让网络重试和人工纠错继续依赖运气。第四步才考虑抽象共用组件。可以统一操作日志、冲突提示和命令执行骨架但“什么算完成、什么情况下可以取消”必须留给业务定义。过早统一枚举往往只是把不同模块的复杂性压进一个越来越长的 switch。体验时可按资产借用单、归还单、资产卡片三个入口查看真实行为。本文状态矩阵用于解释通用设计资产实现以实际的借用和归还语义为准不把未实现的部分执行或通用补偿引擎当作已有功能。常见问题一个状态字段一定是错误设计吗不是。简单、严格线性的业务可以只有一个状态。问题是把互相独立、会同时存在的业务事实塞进同一字段导致组合越来越难解释。审批通过后是否应该统一进入“待执行”不应一刀切。有的业务在审批回调中就完成主数据变更或资产占用有的还需要仓库、财务等角色继续执行。状态应对应真实动作不为了形式完整增加无用步骤。有了数据库事务是否还需要幂等需要。本地事务保证一次执行内部的提交关系不自动识别两次请求是不是同一业务意图也不保证跨系统消息只投递一次。作废单据可以物理删除吗是否允许删除由业务留存与审计要求决定。已经形成履行事实的单据通常需要保留可解释的来源和反向记录不能只因为界面想隐藏就删除支撑台账的证据。结语一个可维护的企业系统不是状态枚举最多的系统而是每个状态都能回答明确问题、每个动作都能找到业务证据的系统。审批、履行和有效性分清之后前端更容易解释后端更容易校验发生异常时也更容易恢复。RuoYi Office 的资产借用归还和流程回调提供了实际业务基础。在这些事实之上逐步补齐命令、并发与历史治理比把所有问题交给一个 status 字段更接近企业系统长期运行的真实需要。如果这篇对你有用点个「在看」或收藏。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
