当前位置：首页 > news >正文

别再只写CRUD了！用SpringBoot+MyBatis实现CRM，这些设计亮点值得抄作业

news 2026/4/19 23:32:24

从CRUD到企业级架构：SpringBoot+MyBatis构建高可用CRM的五个关键设计

当你的Java开发经验超过三年，CRUD早已成为肌肉记忆，但面对企业级CRM系统时，真正的挑战才刚刚开始。我曾见过太多"看似功能完整"的客户管理系统，上线三个月后就被贴上"难以维护"的标签，最终沦为技术债的重灾区。本文将揭示那些教科书不会告诉你的实战经验——如何用SpringBoot和MyBatis打造一个经得起业务增长考验的CRM架构。

1. 权限控制的黄金组合：AOP+注解的精细化治理

在传统CRM中，权限控制往往停留在简单的角色判断层面，而现代企业需要的是细粒度的权限治理。我们采用的三层权限体系，让权限控制从UI贯穿到数据访问层：

@Target({ElementType.METHOD, ElementType.TYPE}) @Retention(RetentionPolicy.RUNTIME) public @interface DataPermission { String deptAlias() default ""; String userAlias() default ""; String customerField() default "create_by"; }

配合AOP切面实现的数据权限拦截器，可以动态修改SQL语句：

@Aspect @Component public class DataPermissionAspect { @Before("@annotation(dataPermission)") public void doBefore(DataPermission dataPermission) { String deptFilter = buildDeptFilter(dataPermission.deptAlias()); String userFilter = buildUserFilter(dataPermission.userAlias()); // 通过ThreadLocal将过滤条件传递给MyBatis拦截器 PermissionContext.setFilter(deptFilter + " AND " + userFilter); } }

这种设计带来的直接收益是：

方法级权限控制精度达到字段级别
权限规则变更无需修改业务代码
与Spring Security天然集成，形成完整的权限体系

注意：权限注解应保持最小化设计，避免过度复杂的权限逻辑影响代码可读性

2. 状态机的艺术：用枚举驾驭复杂业务流程

客户服务流程中的状态流转是CRM中最易出错的环节之一。我们采用状态机模式+枚举的策略：

public enum CustomerServiceStatus { CREATED("创建", Arrays.asList(ASSIGNED)), ASSIGNED("已分配", Arrays.asList(PROCESSING, CANCELLED)), PROCESSING("处理中", Arrays.asList(FEEDBACK, CANCELLED)), FEEDBACK("待反馈", Arrays.asList(COMPLETED, REOPENED)), COMPLETED("已完成", Collections.emptyList()), CANCELLED("已取消", Collections.emptyList()), REOPENED("重新打开", Arrays.asList(PROCESSING)); private final String desc; private final List<CustomerServiceStatus> nextStates; public boolean canTransferTo(CustomerServiceStatus next) { return nextStates.contains(next); } }

配合状态变更拦截器，实现业务流程的强约束：

public class StateTransitionInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { CustomerService current = getCurrentState(); CustomerService target = getTargetState(); if (!current.getStatus().canTransferTo(target.getStatus())) { throw new IllegalStateException("状态转换不合法"); } return true; } }

这种设计解决了传统CRM中的典型问题：

非法状态流转导致的业务异常
状态逻辑分散在各处难以维护
新成员理解业务规则的认知成本

3. 定时任务的优雅解耦：Quartz与业务逻辑的边界划分

大多数CRM中的定时任务实现都存在两个致命问题：与业务代码高度耦合和缺乏弹性调度能力。我们的解决方案是：

任务调度层（基础设施层）：

public class QuartzConfig { @Bean public SchedulerFactoryBean scheduler(DataSource dataSource) { SchedulerFactoryBean factory = new SchedulerFactoryBean(); factory.setDataSource(dataSource); factory.setOverwriteExistingJobs(true); factory.setAutoStartup(true); return factory; } }

业务命令层（领域层）：

public interface CustomerJobCommand { void checkLostCustomers(); void generateMonthlyReports(); }

任务执行层（适配器层）：

public class CustomerJobExecutor implements Job { @Override public void execute(JobExecutionContext context) { String commandName = context.getMergedJobDataMap().getString("command"); CustomerJobCommand command = applicationContext.getBean(commandName, CustomerJobCommand.class); command.execute(); } }

关键优势对比：

传统方案	改进方案
业务逻辑嵌入Job类	业务逻辑独立于调度框架
修改调度需重新部署	动态调整调度策略
难以单元测试	命令对象可单独测试
失败处理机制缺失	内置重试和死信队列

4. 全局异常处理的工程化实践

CRM系统中异常处理常被忽视，导致出现：

前端展示的技术栈信息暴露
相同异常在不同接口响应格式不一致
关键异常信息丢失

我们的异常处理架构包含以下核心组件：

异常分类体系：

BaseException ├── BusinessException（业务异常） │ ├── CustomerException │ └── OrderException ├── SystemException（系统异常） │ ├── DatabaseException │ └── CacheException └── ThirdPartyException（第三方服务异常）

异常转换器（将异常转为标准响应）：

@ControllerAdvice public class ExceptionTranslator { @ExceptionHandler(BusinessException.class) public ResponseEntity<ErrorDTO> handleBusinessException(BusinessException ex) { return ResponseEntity .status(HttpStatus.BAD_REQUEST) .body(ErrorDTO.from(ex)); } @ExceptionHandler(SystemException.class) public ResponseEntity<ErrorDTO> handleSystemException(SystemException ex) { return ResponseEntity .status(HttpStatus.INTERNAL_SERVER_ERROR) .body(ErrorDTO.from(ex)); } }

错误码规范：

# 错误码设计规则：模块(2位)+错误类型(2位)+序号(2位) customer.not_found=100101=客户不存在 customer.invalid_status=100102=客户状态非法 order.amount_exceed=200101=订单金额超限

配合前端拦截器实现统一的错误处理：

axios.interceptors.response.use(null, error => { const errorDTO = error.response.data; if (errorDTO.code === '100101') { router.push('/customer-not-found'); } else { showErrorToast(errorDTO.message); } return Promise.reject(error); });

5. 前后端协作的枚举契约

前后端分离架构中，枚举值的同步是个容易被忽视的问题。我们采用的方案是：

后端枚举定义：

@JsonFormat(shape = JsonFormat.Shape.OBJECT) public enum CustomerSource { WEB(1, "官网"), STORE(2, "门店"), REFERRAL(3, "转介绍"); private int code; private String desc; // getters }

自动生成TypeScript类型（通过Build插件）：

// generated-enums.ts export enum CustomerSource { WEB = { code: 1, desc: "官网" }, STORE = { code: 2, desc: "门店" }, REFERRAL = { code: 3, desc: "转介绍" } }

前端枚举工具类：

export class EnumUtils { static getOptions(enumObj: any) { return Object.values(enumObj).map(item => ({ label: item.desc, value: item.code })); } static getDesc(enumObj: any, code: number) { return Object.values(enumObj) .find(item => item.code === code)?.desc || ''; } }

这种模式带来的协作效率提升：