# Proposal: 拆分个人和企业利率定价发起接口 ## 概述 将现有的统一利率定价发起接口 (`POST /loanPricing/workflow/create`) 拆分为两个独立的接口: - 个人客户发起接口 (`POST /loanPricing/workflow/create/personal`) - 企业客户发起接口 (`POST /loanPricing/workflow/create/corporate`) ## 背景 当前系统中,`LoanPricingWorkflow` 实体包含了个人和企业客户的所有字段。当发起流程时,根据客户类型(custType)的不同,需要填写的字段存在差异: - **个人客户**:需要填写个人特有字段(如是否有经营佐证、循环功能等) - **企业客户**:需要填写企业特有字段(如贸易和建筑业企业标识、省农担担保贷款、绿色贷款、科技型企业、贷款期限等) 将接口拆分可以带来以下好处: 1. **接口契约更清晰**:每个接口只包含对应客户类型的字段 2. **验证更精确**:可以在 DTO 层面进行字段验证 3. **文档更友好**:API 文档可以分别展示个人和企业的字段 4. **维护性更好**:字段变更不会影响另一类型的客户 ## 影响范围 ### 后端变更 - 创建新的 DTO 类:`PersonalLoanPricingCreateDTO` 和 `CorporateLoanPricingCreateDTO` - 在 `LoanPricingWorkflowController` 中添加两个新接口 - 修改 `ILoanPricingWorkflowService` 接口,添加两个新的创建方法 - 实现 `LoanPricingWorkflowServiceImpl` 中的新方法 - 保留原有接口以保持向后兼容(可选,建议标记为 Deprecated) ### 前端变更 > **注:本次变更仅涉及后端,前端暂不修改** ### 数据库变更 需要向 `loan_pricing_workflow` 表添加以下字段: | 字段名 | 类型 | 说明 | 适用客户 | |-----------------------|--------------|------------------------|-------| | id_num | varchar(100) | 证件号码 | 个人、企业 | | loan_loop | varchar(10) | 循环功能 | 个人 | | is_trade_construction | varchar(10) | 贸易和建筑业企业标识(抵质押类上调20BP) | 企业 | | is_green_loan | varchar(10) | 绿色贷款(最多下降5BP) | 企业 | | is_tech_ent | varchar(10) | 科技型企业(最多下降5BP) | 企业 | | loan_term | varchar(50) | 贷款期限 | 企业 | **迁移脚本位置**: `sql/add_missing_fields.sql` 同时需要更新 `LoanPricingWorkflow` Entity 类,添加对应的属性和字段映射注解。 ## 设计方案 详见 `design.md` ## 风险和考虑 1. **向后兼容性**:原有接口 `POST /loanPricing/workflow/create` 继续保留 - 原有接口不做标记为 Deprecated 的处理 - 新旧接口共存,供前端自由选择使用 2. **数据迁移**:需要执行数据库迁移脚本添加新字段,但不涉及现有数据的迁移 3. **测试覆盖**:需要为新接口编写测试用例 ## 依赖关系 - **数据库迁移必须最先执行**:所有后端开发依赖于新字段添加完成 - 依赖现有的 `LoanPricingWorkflow` 实体 - 依赖现有的 `ILoanPricingWorkflowService` 服务层 ## 验收标准 1. **数据库变更**:所有新字段成功添加到数据库表,且可以正确存储和检索数据 2. **Entity 类更新**:`LoanPricingWorkflow` 实体类包含所有新增字段的属性和映射 3. **个人客户接口**:个人客户发起接口只接受个人相关的字段 4. **企业客户接口**:企业客户发起接口只接受企业相关的字段 5. **接口功能**:两个接口都能成功创建利率定价流程记录,包括新增字段的保存 6. **字段验证**:字段验证正确生效 7. **API 文档**:API 文档正确显示两个接口的差异