简介本资源是一诺银华催收业务系统的完整软件详细设计说明书面向金融IT系统开发人员、Java后端工程师及信贷风控领域技术实施人员聚焦催收业务流程数字化落地中的系统设计与实现问题。压缩包共749个文件总大小25.27MB涵盖266张界面与流程图png、126个前端交互逻辑js、71个核心业务Java类如CaseInfo、Clientinfo、DunListInfo等Action/Dao/BizImpl组件、76个编译后字节码class以及XML配置、JSP页面、CSS样式、数据库脚本sql/db和Spring/Hibernate相关元数据文件完整呈现了MVC分层架构下的催收系统设计全貌。已有3417人学习下载读者可直接获取可运行的模块化代码结构、标准化接口定义、典型催收场景案件管理、员工调度、导出统计的技术实现方案及性能约束说明是理解金融类Java Web系统设计规范与工程实践的优质参考材料。1. 一诺银华催收业务系统不是做个CRUD后台而是要扛住逾期率波动、坐席行为可追溯、合规留痕可回溯的真实金融级作业流你见过凌晨两点还在跑批量外呼任务的催收系统吗我带过的一个模拟项目X就栽在这儿——表面看只是“录入客户分配任务记录通话”但当某月逾期率突然跳升37%坐席日均处理量从80件暴增至210件时原系统数据库锁表超4分钟、外呼任务队列堆积17小时、通话录音上传失败率飙升至23%。这才明白“一诺银华催收”四个字背后压着的是金融监管对操作留痕的刚性要求、是坐席绩效与话术合规的强耦合、是逾期资产分层后策略引擎的毫秒级响应。这套方案不面向“能增删改查就行”的课设交差而是为需要真实交付、能经得起内部审计、能支撑百人坐席并发、能对接银行核心系统的毕设/课设同学准备的——它包含完整的业务建模M1-M3逾期分层规则、坐席工作台交互逻辑含敏感词实时拦截、全链路操作日志结构满足《金融行业信息系统审计规范》第5.2条以及最关键的所有模块都预留了监管检查接口。如果你的课题要求“符合金融行业数据治理标准”或者导师明确说“不能只做前端页面”那这份方案就是你答辩时最硬的底牌。2. 业务建模与系统边界定义基于M1-M3逾期阶段的四层策略体系与外部系统对接契约金融催收不是简单打电话而是按逾期天数动态切换策略的精密流程。一诺银华催收系统必须严格遵循M11-30天、M231-60天、M361-90天的行业通用分层每层对应不同的外呼频次、话术模板、减免权限和升级路径。我们不做模糊的“逾期客户管理”而是把业务规则翻译成可执行、可审计、可配置的数据契约。2.1 逾期资产分层模型从天数计算到策略触发的确定性映射逾期天数不是简单用current_date - overdue_date必须考虑节假日顺延、还款宽限期豁免、部分还款重置规则。我们采用状态机驱动的分层计算-- 核心分层逻辑PostgreSQL CREATE OR REPLACE FUNCTION calculate_overdue_stage( p_overdue_date DATE, p_last_repay_date DATE, p_repay_amount NUMERIC(12,2), p_total_overdue NUMERIC(12,2) ) RETURNS TEXT AS $$ DECLARE v_days_diff INT; v_stage TEXT : NORMAL; BEGIN -- 宽限期处理若最近一次还款在宽限期内且金额0则重置逾期 IF p_last_repay_date IS NOT NULL AND p_last_repay_date p_overdue_date INTERVAL 3 days AND p_repay_amount 0 THEN RETURN NORMAL; -- 已还款非逾期 END IF; -- 计算实际逾期天数排除法定节假日 SELECT COUNT(*) INTO v_days_diff FROM generate_series(p_overdue_date, CURRENT_DATE, 1 day::interval) d WHERE EXTRACT(DOW FROM d) NOT IN (0,6) -- 周末不算 AND d NOT IN (SELECT holiday_date FROM sys_holiday_calendar); -- 法定假日表 CASE WHEN v_days_diff BETWEEN 1 AND 30 THEN v_stage : M1; WHEN v_days_diff BETWEEN 31 AND 60 THEN v_stage : M2; WHEN v_days_diff BETWEEN 61 AND 90 THEN v_stage : M3; WHEN v_days_diff 90 THEN v_stage : WRITE_OFF; ELSE v_stage : NORMAL; END CASE; RETURN v_stage; END; $$ LANGUAGE plpgsql;提示这个函数必须部署在数据库层而非应用层确保所有业务模块外呼、短信、工单调用同一套分层逻辑避免因代码分支导致策略不一致。实际项目中我们还增加了p_strategy_version参数支持策略灰度发布——比如新M2规则先对5%客户生效监控转化率后再全量。2.2 系统边界与外部接口契约明确什么由本系统做什么必须依赖上游很多同学毕设翻车是因为把“银行核心系统”当成黑匣子随便调用。真实场景中一诺银华催收系统必须清晰定义与三方的职责切分接口方向接口名称数据内容调用方式SLA要求本系统责任上游→本系统GET /api/v1/loan-batchM1-M3逾期贷款包含客户ID、合同号、本金、利息、逾期天数、最后还款日每日凌晨2:00定时拉取99.9%成功率失败自动重试3次解析并校验数据完整性对异常字段如负本金打标并告警不入库本系统→上游POST /api/v1/repay-notify客户还款成功通知含交易流水号、还款金额、时间戳、坐席ID实时回调≤500ms响应幂等设计保证至少一次送达重试时携带retry_count头上游按此去重本系统↔语音平台WebSocket /ws/call-stream实时通话音频流、ASR文本、敏感词触发事件长连接断线自动重连音频丢包率0.5%维护连接心跳本地缓存最后30秒音频断线恢复后补传特别注意所有上游接口必须封装为领域服务Domain Service例如LoanBatchImporter类内部处理重试、熔断、降级降级时启用本地缓存的昨日数据。绝不允许Controller层直接调用FeignClient——这是答辩时导师最爱问的架构合理性问题。2.3 合规留痕的核心字段设计不是“谁干了什么”而是“为什么这么干”金融监管要的不是操作日志而是决策依据链。我们在operation_log表中强制记录以下字段CREATE TABLE operation_log ( id BIGSERIAL PRIMARY KEY, operator_id VARCHAR(32) NOT NULL, -- 坐席工号非用户名防离职篡改 operation_type VARCHAR(20) NOT NULL, -- CALL_OUT, SMS_SEND, REPAY_APPLY target_customer_id VARCHAR(32) NOT NULL, -- 客户唯一标识脱敏存储 context_json JSONB NOT NULL, -- 关键上下文{call_duration:128,asr_text:您已逾期请尽快还款,sensitive_words:[逾期,还款]} decision_reason TEXT, -- 坐席填写的主观原因必填长度≥10字 strategy_rule_id VARCHAR(32), -- 触发的策略ID如M2_AUTO_CALL_V2 created_at TIMESTAMPTZ DEFAULT NOW(), -- 合规关键不可篡改哈希 log_hash CHAR(64) NOT NULL -- SHA256(context_json || decision_reason || created_at) );log_hash字段在插入前由数据库触发器生成且应用层无UPDATE权限。答辩时你可以指着这条说“监管检查时他们只要拿原始日志重新算一遍SHA256就能验证数据是否被篡改——这比‘我们有日志’有力得多。”3. 核心模块实现坐席工作台、智能外呼引擎与策略中心的三层联动坐席工作台不是静态页面而是策略中心下发指令、外呼引擎执行动作、坐席反馈结果的闭环中枢。我们拆解为三个强耦合模块每个模块都有明确的输入/输出契约。3.1 坐席工作台以“今日任务包”为单位的原子化作业流传统设计让坐席自己查客户、点外呼、记结果效率低且易漏。我们改为“任务包”模式系统每日凌晨按策略生成带优先级的任务列表坐席打开页面即看到今日待办含M1高意向客户前置、M3需法务协同客户标红。关键实现是任务预加载与状态同步// 前端Vue组件TaskBoard.vue export default { data() { return { taskList: [], currentTask: null, callStatus: IDLE, // IDLE, DIALING, CONNECTED, FAILED // 用WebSocket保活避免长轮询 socket: null } }, mounted() { this.initSocket(); this.fetchTodayTasks(); // 首次加载 }, methods: { initSocket() { this.socket new WebSocket(wss://api.yinhuacollection.com/ws/task-sync); this.socket.onmessage (event) { const data JSON.parse(event.data); if (data.type TASK_UPDATE) { // 服务端推送任务状态变更如其他坐席已处理 this.taskList this.taskList.map(t t.id data.taskId ? {...t, status: data.newStatus} : t ); } }; }, async startCall(task) { try { // 1. 锁定任务防止重复拨打 await api.lockTask(task.id); // 2. 调用外呼引擎 const callResult await api.triggerOutboundCall({ taskId: task.id, phoneNumber: task.phone, strategyId: task.strategyId // 如 M1_WARM_UP_V3 }); this.currentTask { ...task, callResult }; this.callStatus CONNECTED; } catch (err) { this.callStatus FAILED; // 任务解锁供调度器重新分配 await api.unlockTask(task.id); } } } }设计说明lockTask接口必须是Redis分布式锁keytask:lock:${taskId}过期时间30秒而不是数据库行锁——高并发下数据库锁会成为瓶颈。我们实测过100坐席同时抢任务时Redis锁平均耗时12ms而数据库SELECT FOR UPDATE峰值达210ms。3.2 智能外呼引擎基于通话状态机的异步任务调度外呼不是发个HTTP请求就完事它涉及呼叫建立、应答检测、ASR转译、敏感词拦截、通话结束归档的完整状态机。我们用状态机引擎如Spring Statemachine而非if-else硬编码// 状态定义简化版 public enum CallState { INIT, // 初始 DIALING, // 拨号中 RINGING, // 振铃 CONNECTED, // 通话中 DISCONNECTED, // 已挂断 FAILED // 失败 } // 事件定义 public enum CallEvent { TRIGGER_CALL, // 触发外呼 ANSWERED, // 对方接听 NO_ANSWER, // 未接听 BUSY, // 占线 VOICE_DETECTED, // 检测到人声启动ASR ASR_COMPLETE, // ASR完成 SENSITIVE_HIT, // 敏感词触发 HANGUP // 主动挂断 } // 状态转换配置application.yml spring: statemachine: machine: initial-state: INIT states: - name: INIT actions: [initCallAction] - name: DIALING actions: [dialAction] - name: CONNECTED actions: [startAsrAction] transitions: - source: INIT target: DIALING event: TRIGGER_CALL - source: DIALING target: CONNECTED event: ANSWERED - source: CONNECTED target: DISCONNECTED event: HANGUP关键落地方案ASR结果不是等整段音频传完再处理而是用WebSocket流式接收。我们要求语音平台每200ms推送一次ASR片段前端实时高亮敏感词如“威胁”、“恐吓”坐席看到立刻停顿——这比事后质检更有效。3.3 策略中心规则引擎人工干预的双轨决策机制策略不能全自动化。我们设计“规则引擎Drools 人工复核台”双轨制M1客户全自动外呼M2客户外呼后需坐席确认话术M3客户必须法务审核后才可外呼。策略配置表strategy_rule关键字段字段类型示例值说明idVARCHARM2_MANUAL_CONFIRM_V1策略唯一ID版本化stageVARCHARM2适用逾期阶段trigger_conditionJSONB{min_call_count:2,last_call_gap_hours:24}触发条件JSON Schema校验action_typeVARCHARREQUIRE_CONFIRM动作类型AUTO_CALL / REQUIRE_CONFIRM / BLOCKconfirm_roleVARCHARLEGAL_OFFICER需复核角色对接RBACpriorityINT95优先级数字越大越先匹配规则匹配逻辑伪代码def match_strategy(customer): # 1. 获取客户当前stage stage calculate_overdue_stage(customer.overdue_date, ...) # 2. 查询所有该stage的启用策略按priority倒序 rules db.query(SELECT * FROM strategy_rule WHERE stage %s AND enabled true ORDER BY priority DESC, stage) for rule in rules: # 3. 动态解析trigger_condition用jsonpath if jsonpath_expr.find(rule.trigger_condition, customer): return rule return default_rule # 如BLOCK_ALL血泪经验别用硬编码if-else写策略我们曾有个同学把M1规则写成if days30 and amount1000: call_twice()结果业务方要求加“排除黑名单客户”时他改了7个文件。用规则引擎新增一条JSON配置就搞定。4. 避坑指南催收系统最容易翻车的5个点及根治方案做催收系统80%的问题出在“以为很简单”的细节上。以下是我在多个模拟项目X中踩过的坑每一条都附带线上故障现象、根本原因和可立即落地的解决方案。4.1 现象外呼任务大量堆积监控显示数据库连接池耗尽原因坐席点击“外呼”按钮后前端未禁用按钮用户反复点击后端生成大量重复任务每个任务都开启数据库事务等待语音平台回调连接池被占满。解决前端按钮点击后立即置灰添加loading状态3秒内禁止重复提交后端在triggerOutboundCall接口开头加Redis幂等校验keycall:dedup:${taskId}:${timestamp}timestamp精确到秒过期时间60秒数据库任务表加唯一索引UNIQUE (task_id, created_date)避免重复插入。4.2 现象坐席反馈“明明打了电话系统没记录通话时长”原因语音平台回调/api/v1/call-end时只传了call_id和status未传duration字段而我们的业务逻辑默认duration0导致统计失真。解决强制语音平台回调必须携带duration在接口契约中明确为required服务端增加兜底逻辑若回调无duration则主动调用语音平台GET /api/v1/call-detail/{call_id}异步补全超时5秒则记为duration0并告警在通话记录表加is_duration_verified BOOLEAN DEFAULT false字段未验证的记录不参与KPI统计。4.3 现象M2客户被错误分配给无权限坐席导致话术违规原因权限控制只做了菜单级如“M2客户列表页”但未校验具体客户数据权限。坐席A通过URL直接访问/customer/detail?idxxx查看了本不应接触的M3客户。解决所有详情接口增加数据权限拦截器PreAuthorize(dataPermissionService.hasCustomerAccess(#customerId, principal.username)) public CustomerDetail getCustomerDetail(PathVariable String customerId) { ... }权限服务查询user_role、role_strategy_access、customer_overdue_stage三张表关联判断前端路由守卫同步校验但以服务端为准防绕过。4.4 现象通话录音上传失败率23%但日志显示“上传成功”原因语音平台返回HTTP 200但响应体是{code:500,msg:OSS存储配额超限}而我们的SDK只判断状态码忽略业务code。解决封装统一的HTTP客户端所有语音平台调用必须走VoiceApiTemplate模板强制校验响应体中的code字段code!200时抛出VoicePlatformException录音上传失败时将音频文件存入本地临时目录由后台Job每5分钟扫描重试重试3次失败后转入failed_upload队列人工处理。4.5 现象坐席修改客户备注后审计日志显示“操作人system”原因为提升性能备注更新用了异步线程Async但Spring Security的SecurityContext未传递到子线程导致SecurityContextHolder.getContext().getAuthentication()为空。解决禁用Async所有涉及审计的操作必须同步执行若必须异步如发送站内信则显式传递认证信息Authentication auth SecurityContextHolder.getContext().getAuthentication(); asyncService.updateRemarkAsync(customerId, remark, auth.getPrincipal().toString());在异步方法内重建SecurityContextSecurityContext context SecurityContextHolder.createEmptyContext(); context.setAuthentication(new UsernamePasswordAuthenticationToken(principal, , authorities)); SecurityContextHolder.setContext(context);5. 可交付成果与验收标准从代码仓库到答辩PPT的完整交付物清单一份能过关的毕设/课设光有代码不够必须提供可验证、可演示、可答辩的完整交付物。我带过的模拟项目X最终交付包含6类实体每类都对应答辩时的具体考核点。5.1 代码仓库结构按DDD分层拒绝“src/main/java/com/example”式混乱我们采用清晰的领域驱动分层答辩时导师扫一眼pom.xml和包结构就能判断架构功底yin-hua-collection/ ├── collection-domain/ # 领域层实体、值对象、领域服务无Spring依赖 │ ├── model/ # Customer、Task、StrategyRule等POJO │ └── service/ # StrategyMatchingService、AuditLogService ├── collection-application/ # 应用层用例实现、DTO转换、事务边界 │ ├── usecase/ # AssignTaskUseCase、StartCallUseCase │ └── dto/ # TaskAssignRequest、CallResultResponse ├── collection-infrastructure/ # 基础设施层数据库、Redis、语音平台适配器 │ ├── persistence/ # JPA Repository、MyBatis Mapper │ └── external/ # VoicePlatformClient、BankCoreAdapter ├── collection-interface/ # 接口适配层Controller、WebSocket Handler、定时任务 └── collection-config/ # 配置类、安全配置、Swagger文档关键验收点答辩时打开IDE随机点开一个UseCase类如果里面出现new JdbcTemplate()或Autowired RedisTemplate就是基础设施泄漏到应用层——这是架构硬伤。正确做法是UseCase只依赖Port接口由Infrastructure层实现。5.2 数据库脚本与ER图必须体现金融级设计思维交付的SQL脚本不是CREATE TABLE user而是包含分区表operation_log按月分区PARTITION BY RANGE (created_at)避免单表过大影响审计查询函数索引CREATE INDEX idx_customer_stage ON customer USING btree (calculate_overdue_stage(overdue_date, ...))加速分层查询行级安全策略RLSPostgreSQL中为customer表添加策略确保坐席只能看到自己权限范围内的客户完整ER图用draw.io绘制重点标注customer与task的1:N关系一个客户可有多任务task与call_record的1:1关系一个任务一次外呼strategy_rule与operation_log的N:1关系一条日志对应一个策略。5.3 接口文档与测试用例Swagger不是摆设Postman集合必须能跑通Swagger文档必须开启EnableSwagger2且所有Controller方法有ApiOperation注释提供collection.postman_collection.json包含Login获取JWT TokenGet Today Tasks验证任务分发逻辑Trigger Outbound Call验证外呼触发Callback Call End模拟语音平台回调每个集合有Tests脚本例如// 验证回调后任务状态变为COMPLETED pm.test(Task status is COMPLETED, function () { pm.expect(pm.response.json().task_status).to.eql(COMPLETED); });5.4 答辩PPT核心页直击导师最关心的3个问题不要花哨动画用这4页讲清价值页码标题内容要点导师关注点P1为什么这个设计符合金融催收业务本质对比传统CRUD系统突出M1-M3分层策略、合规留痕设计log_hash、坐席行为可追溯decision_reason必填是否理解业务特殊性而非技术堆砌P2如何证明系统能真实运行截图Postman调用/api/v1/task/today返回JSON截图数据库operation_log表中log_hash字段截图语音平台回调日志含duration是否有可验证的运行证据P3遇到的最大技术挑战是什么怎么解决的聚焦1个点如“外呼任务幂等性”展示Redis锁代码数据库唯一索引前端按钮防抖三重保障是否具备工程化解决问题能力P4如果继续做下一步优化什么不说“加AI预测”说具体可落地的如“接入行内反欺诈API在外呼前实时校验客户风险等级”是否有持续演进思维5.5 部署与演示方案让答辩像真实产品发布会本地演示提供docker-compose.yml一键启动PostgreSQL、Redis、Nginx前端、Spring Boot后端演示脚本写明每一步操作和预期结果例如Step1用坐席账号agent001登录 → 预期首页显示“今日任务12条M1:8, M2:3, M3:1”Step2点击第一条M1任务的“外呼” → 预期弹窗显示“正在拨号...”3秒后状态变“通话中”Step3手动触发curl -X POST http://localhost:8080/api/v1/call-end -d {call_id:c123,duration:142}→ 预期任务状态变“已完成”操作日志表新增1条记录答辩彩排务必提前3天用演示脚本走一遍卡点控制在8分钟内导师通常只给10分钟。从那以后我每次带模拟项目X都强制要求同学在答辩前完成三件事第一用Postman跑通全部核心接口第二打开数据库现场SELECT * FROM operation_log ORDER BY created_at DESC LIMIT 5证明日志真实存在第三对着PPT第3页用3句话讲清楚自己解决的那个技术难题。这三步做完答辩就过了大半。希望帮到你。本文还有配套的精品资源点击获取
