搞懂公司采购流程代码实现，面试必问不再慌

官方文档太长抓不住重点？别急，今天带你直击核心。很多后端面试必问“业务流如何代码化”，采购流程就是经典考题。

入口定位：从 HTTP 请求到 Service 层

在实际项目中，采购流程通常以 REST API 为入口。以 Java Spring Boot 为例，Controller 层负责接收请求并做初步校验。

@RestController
@RequestMapping("/api/procurement")
public class ProcurementController {@Autowiredprivate ProcurementService procurementService;// 创建采购申请@PostMapping("/apply")public ResponseEntity<String> createApply(@RequestBody ProcurementRequest request) {// 参数校验，防止非法数据进入核心逻辑if (request.getAmount() <= 0) {return ResponseEntity.badRequest().body("Amount must be positive");}// 调用 Service 层处理业务逻辑String applyId = procurementService.createProcurement(request);return ResponseEntity.ok("Apply created with ID: " + applyId);}
}

这段代码看似简单，但藏着关键设计：职责分离。Controller 只关心“接什么、回什么”，不关心“怎么做”。面试时若被问“如何保证接口幂等性”，这里就是切入点——通过 applyId 做唯一约束，重复请求直接返回已存在记录，而非报错。

核心片段：状态机驱动的采购审批

采购流程的本质是状态流转：草稿 → 待审批 → 审批中 → 已通过/已驳回 → 已执行。官方文档常把这部分拆成十几个接口，初学者容易迷失。其实核心就一个类：状态机管理器。

@Service
public class ProcurementStateMachine {// 定义所有合法状态private static final Map<String, Set<String>> STATE_TRANSITIONS = Map.of("DRAFT", Set.of("PENDING_APPROVAL"),"PENDING_APPROVAL", Set.of("APPROVING", "REJECTED"),"APPROVING", Set.of("APPROVED", "REJECTED"),"APPROVED", Set.of("EXECUTED"),"REJECTED", Set.of() // 终态，不可再流转);// 状态流转核心方法public void transition(String currentStatus, String targetStatus, String applyId) {// 检查当前状态是否允许流转到目标状态Set<String> allowedTargets = STATE_TRANSITIONS.getOrDefault(currentStatus, Set.of());if (!allowedTargets.contains(targetStatus)) {throw new IllegalStateException(String.format("Cannot transition from %s to %s for apply %s", currentStatus, targetStatus, applyId));}// 这里应触发后续动作：如发送通知、记录审计日志、更新数据库log.info("Procurement {} transitioned from {} to {}", applyId, currentStatus, targetStatus);// 实际项目中，此处调用 repository.updateStatus(applyId, targetStatus)// 并发送领域事件，解耦后续通知、报表等逻辑}
}

逐行解析：

STATE_TRANSITIONS 用不可变 Map 定义状态图，避免运行时被篡改。这是参考了Spring Statemachine 开发者文档的最佳实践——状态转移规则应集中管理，而非散落在 if-else 中。
transition 方法不直接操作数据库，而是校验+触发事件。这符合事件驱动架构思想：状态变更是事实，通知、报表是副作用，二者解耦。
面试必问：“如何防止并发下状态错乱？”答案就在这一层——transition 方法需加分布式锁或乐观锁，确保同一时刻只有一个线程能改变某申请的狀態。

设计思想：为什么不用 if-else 堆流程？

很多初学者会写成这样：

if (status == "DRAFT") {// 转待审批
} else if (status == "PENDING_APPROVAL") {// 转审批中
}

问题在哪？扩展性差。新增一个“加急审批”状态，要改 N 处代码，极易漏改。而状态机把规则数据化，新增状态只需在 STATE_TRANSITIONS 加一行，transition 方法零改动。

更深的设计思想是领域模型驱动。采购流程不是一个“接口集合”，而是一个有生命周期的实体。每个状态对应明确的业务含义：

DRAFT：申请人可修改、删除
PENDING_APPROVAL：只读，等待审批人认领
APPROVING：审批人可操作，其他角色只读
APPROVED：触发采购执行，财务可入账

面试时若能说出“状态不是字符串，而是业务语义的载体”，立刻区别于背八股的候选人。

手写简化版：用 Python 实现最小可用状态机

为了加深理解，用 Python 写一个 50 行以内的简化版。重点不在功能完整，而在结构清晰。

from enum import Enum
from typing import Dict, Setclass ProcurementStatus(Enum):DRAFT = "DRAFT"PENDING_APPROVAL = "PENDING_APPROVAL"APPROVING = "APPROVING"APPROVED = "APPROVED"REJECTED = "REJECTED"EXECUTED = "EXECUTED"class ProcurementStateMachine:def __init__(self):# 状态转移表：当前状态 -> 允许的目标状态集合self.transitions: Dict[ProcurementStatus, Set[ProcurementStatus]] = {ProcurementStatus.DRAFT: {ProcurementStatus.PENDING_APPROVAL},ProcurementStatus.PENDING_APPROVAL: {ProcurementStatus.APPROVING, ProcurementStatus.REJECTED},ProcurementStatus.APPROVING: {ProcurementStatus.APPROVED, ProcurementStatus.REJECTED},ProcurementStatus.APPROVED: {ProcurementStatus.EXECUTED},ProcurementStatus.REJECTED: set(),  # 终态ProcurementStatus.EXECUTED: set(),  # 终态}def can_transition(self, current: ProcurementStatus, target: ProcurementStatus) -> bool:"""校验状态流转是否合法"""return target in self.transitions.get(current, set())def transition(self, current: ProcurementStatus, target: ProcurementStatus, apply_id: str) -> None:"""执行状态流转，实际项目中此处持久化+发事件"""if not self.can_transition(current, target):raise ValueError(f"Illegal transition: {current.value} -> {target.value} for {apply_id}")print(f"[AUDIT] Apply {apply_id}: {current.value} -> {target.value}")# 模拟持久化# db.update(apply_id, status=target.value)# 模拟发送领域事件# event_bus.publish(ProcurementStatusChangedEvent(apply_id, current, target))

关键细节：