从CRUD到业务建模：宠物医院系统中的状态机实战
宠物医院管理系统看似简单，实则暗藏复杂业务逻辑。许多开发者习惯性地将这类系统简化为增删改查（CRUD）操作，却忽略了其中蕴含的业务建模精髓。本文将带你深入宠物医院的核心业务流程，探索如何用状态机优雅地处理预约、订单和就诊等复杂状态流转。
1. 业务建模的常见误区与破局之道
刚接触业务系统开发时，我们往往陷入"数据库驱动开发"的陷阱——先设计表结构，然后围绕表实现CRUD。这种方式在简单系统中尚可应付，但面对宠物医院这样的多角色、多状态系统时，代码很快就会变得难以维护。
以预约流程为例，传统CRUD式开发可能会这样设计：
// 典型的贫血模型示例 public class Appointment { private Long id; private Date time; private String status; // "WAIT_AUDIT", "CONFIRMED", "COMPLETED" // 其他字段... // 只有getter/setter，没有业务逻辑 }这种设计的弊端显而易见：业务逻辑散落在Service层各处，状态变更缺乏约束，容易出现非法状态流转。更糟糕的是，当业务规则变化时，我们需要修改大量分散的代码。
**领域驱动设计（DDD）**为我们提供了更好的思路。通过识别核心业务实体和状态流转，我们可以构建更健壮的模型。在宠物医院系统中，以下几个领域尤其值得关注：
- 预约管理：涉及待审核、已确认、已完成等状态
- 订单处理：包含待支付、已发货、已签收等环节
- 就诊流程：从挂号、诊断到治疗的完整周期
2. 状态机：业务规则的优雅表达
状态机是管理复杂状态流转的利器。它明确定义了状态、事件以及状态之间的转换规则，可以有效防止非法状态变更。
2.1 预约状态机设计
让我们用枚举实现一个强类型的预约状态机：
public enum AppointmentStatus { WAIT_AUDIT { @Override public boolean canTransitionTo(AppointmentStatus newStatus) { return newStatus == CONFIRMED || newStatus == CANCELLED; } }, CONFIRMED { @Override public boolean canTransitionTo(AppointmentStatus newStatus) { return newStatus == COMPLETED || newStatus == CANCELLED; } }, COMPLETED { @Override public boolean canTransitionTo(AppointmentStatus newStatus) { return false; // 终态 } }, CANCELLED { @Override public boolean canTransitionTo(AppointmentStatus newStatus) { return false; // 终态 } }; public abstract boolean canTransitionTo(AppointmentStatus newStatus); }在Appointment实体中使用这个枚举：
public class Appointment { private AppointmentStatus status; public void confirm() { if (!status.canTransitionTo(AppointmentStatus.CONFIRMED)) { throw new IllegalStateException("非法状态变更"); } this.status = AppointmentStatus.CONFIRMED; } // 其他状态变更方法... }2.2 订单状态机的进阶实现
对于更复杂的订单流程，我们可以使用状态模式：
public interface OrderState { void pay(Order order); void deliver(Order order); void sign(Order order); void cancel(Order order); } public class UnpaidState implements OrderState { @Override public void pay(Order order) { // 支付逻辑 order.setState(new PaidState()); } // 其他方法实现... } public class Order { private OrderState state; public void pay() { state.pay(this); } // 其他委托方法... }这种设计将每种状态的行为封装在单独的类中，符合单一职责原则，也更容易扩展。
3. 分层架构中的业务逻辑分配
状态机解决了业务规则的内聚问题，但我们还需要合理规划代码结构。常见的分层误区包括：
- 贫血模型：所有业务逻辑都塞进Service
- 上帝Service：单个Service处理所有业务
- 层间耦合：上层直接依赖下层实现细节
3.1 改进的分层方案
| 层级 | 职责 | 宠物医院示例 |
|---|---|---|
| 展现层 | 处理HTTP请求/响应 | 提供RESTful API |
| 应用层 | 协调领域对象 | 预约审核服务 |
| 领域层 | 核心业务逻辑 | 预约状态机 |
| 基础设施层 | 技术细节实现 | 数据库访问 |
应用层服务示例：
@Service @RequiredArgsConstructor public class AppointmentApplicationService { private final AppointmentRepository repository; @Transactional public void confirmAppointment(Long appointmentId) { Appointment appointment = repository.findById(appointmentId) .orElseThrow(() -> new AppointmentNotFoundException(appointmentId)); appointment.confirm(); repository.save(appointment); // 可以在这里触发领域事件 eventPublisher.publish(new AppointmentConfirmedEvent(appointmentId)); } }3.2 领域事件的巧妙运用
领域事件可以帮助解耦系统组件。例如，当预约确认时：
public class AppointmentConfirmedHandler { @EventListener public void handle(AppointmentConfirmedEvent event) { // 发送通知 notificationService.sendAppointmentConfirmed(event.getAppointmentId()); // 更新医生日程 scheduleService.updateDoctorSchedule(event.getAppointmentId()); } }4. 前端状态管理的协同设计
后端的状态机设计需要与前端协同工作。Vuex或Pinia的状态管理可以镜像后端状态：
// 前端状态定义 const appointmentStates = { WAIT_AUDIT: { actions: ['confirm', 'cancel'], color: 'orange' }, CONFIRMED: { actions: ['complete', 'cancel'], color: 'green' } // 其他状态... } // 使用示例 <template> <button v-for="action in appointmentStates[appointment.status].actions" @click="handleAction(action)" :class="`bg-${appointmentStates[appointment.status].color}-500`"> {{ action }} </button> </template>这种前后端一致的状态管理可以显著减少bug，并提高代码可维护性。
5. 实战中的经验与陷阱
在实际项目中应用状态机时，有几个关键点需要注意：
状态持久化：如何将状态机持久化到数据库
- 方案一：存储状态枚举值
- 方案二：使用状态模式时存储当前状态类型
状态变更日志：记录完整的状态变更历史
CREATE TABLE appointment_state_transitions ( id BIGINT PRIMARY KEY, appointment_id BIGINT, from_state VARCHAR(50), to_state VARCHAR(50), changed_at TIMESTAMP, changed_by VARCHAR(100) );并发控制：防止并发状态修改
@Transactional public void confirmAppointment(Long id) { Appointment appointment = repository.findByIdWithLock(id); // ... }分布式环境：在微服务架构中，考虑使用Saga模式管理跨服务状态
6. 测试策略保障状态安全
状态机的正确性至关重要。我们应该为状态机编写详尽的测试：
class AppointmentStatusTest { @Test void shouldAllowValidTransition() { assertTrue(AppointmentStatus.WAIT_AUDIT.canTransitionTo(AppointmentStatus.CONFIRMED)); } @Test void shouldPreventInvalidTransition() { assertThrows(IllegalStateException.class, () -> { Appointment appointment = new Appointment(AppointmentStatus.COMPLETED); appointment.confirm(); }); } }对于复杂业务场景，可以考虑使用状态机测试工具如GraphWalker来自动生成测试路径。
7. 从项目实践到设计思维
宠物医院项目虽然不大，但包含了业务系统设计的核心要素。通过这个项目，我们可以提炼出一些通用的设计原则：
- 识别核心状态：找出系统中的关键状态及其流转
- 封装业务规则：将规则内聚在领域对象中
- 明确界限：划分清晰的上下文边界
- 持续演进：随着业务理解加深不断重构模型
真正的业务建模能力不在于掌握某种框架，而在于这种分析问题和封装复杂性的思维方式。当你下次面对CRUD需求时，不妨多问一句：这背后是否隐藏着值得挖掘的业务模型？
