3. 新核心系统认知
从旧核心迁移到新核心，最危险的不是“数据搬不过去”，而是团队仍然用旧核心的思维去理解新系统。旧核心往往以交易为中心、参数分散、产品逻辑硬编码；新核心则以客户为中心、参数集中、产品可配置。若不能建立对新核心架构与参数模型的正确认知，迁移就会退化为“字段对字段”的机械搬运，最终导致产品行为失真、参数冲突和上线后频繁回退。
一、核心原理：新核心的三层架构与参数模型
新核心通常采用“渠道接入层—产品服务层—账务核心层”的分层架构。渠道层负责协议转换与流量控制；产品服务层承载产品工厂、参数引擎和定价规则；账务核心层负责总账、分户账和交易记账。迁移适配的关键在于：旧核心的产品参数必须被正确映射到新核心的产品服务层，而不是直接写入账务层。
新核心的参数模型一般分为四类：产品级参数（如产品码、币种、期限类型）、条件级参数（如利率档期、费率区间）、客户级参数（如客户等级、协议利率）、渠道级参数（如限额、开关）。旧核心中这些参数常散落在交易码、账户表和产品表中，迁移时必须先做“参数归位”，再谈数据转换。
迁移适配的核心判断：旧核心的一个“产品”在新核心中可能对应“产品+条件+客户协议”三个对象。若只迁移产品码，条件与协议丢失，产品行为必然偏离。
二、产品工厂理念：从“写死”到“装配”
产品工厂的本质是把金融产品拆解为可复用的“参数组件”，通过组合装配形成具体产品。例如，一个定期存款产品可由“期限组件+利率组件+计息组件+提前支取组件”装配而成。迁移时，旧核心的硬编码逻辑需要被识别并拆解为组件配置。
以下是一个产品工厂配置片段的示意，展示如何用参数描述产品行为：
product:
code: TD_001
name: 个人整存整取
components:
- term: {type: FIXED, values: [3M, 6M, 1Y, 2Y, 3Y]}
- rate: {mode: TIERED, table: RATE_TD_001}
- interest: {method: SIMPLE, dayCount: ACT/365}
- withdraw: {early: ALLOW, penaltyRate: 0.35%}
channelLimit:
- channel: MOBILE
singleLimit: 500000
dailyLimit: 2000000
迁移适配要点是：先建立旧核心产品与新产品工厂组件的映射表，再逐项验证组件参数是否覆盖旧产品行为。对于旧核心中无法拆解的“特殊交易”，应作为例外清单单独处理，而不是强行塞入标准组件。
三、迁移适配流程与场景案例
一个可落地的迁移适配流程如下：
- 产品盘点：梳理旧核心全部产品码、交易码及关联参数表。
- 参数归位：将旧参数按产品级、条件级、客户级、渠道级分类。
- 组件映射：建立旧参数到新产品工厂组件的映射关系。
- 差异分析：识别无法映射的参数，形成例外清单。
- 仿真验证：用新核心参数引擎跑批，对比新旧产品行为。
- 灰度切换：按产品优先级分批迁移，保留回退路径。
某银行在迁移“通知存款”产品时，旧核心将“提前通知天数”写死在交易码中，新核心要求该参数配置在产品条件级。迁移团队最初直接跳过该参数，导致仿真时客户提前支取未触发通知罚息。复盘发现：旧核心的“交易码隐含参数”必须显式提取，否则产品行为丢失。
常见误区：把新核心当作“字段更多”的旧核心，只做字段映射而不做参数模型重构。结果是数据迁移成功，但产品逻辑错误，上线后需大量手工调账。
四、迁移适配检查清单
| 检查项 | 旧核心表现 | 新核心要求 | 适配动作 |
|---|---|---|---|
| 产品定义 | 产品码+交易码硬编码 | 产品工厂组件装配 | 拆解组件并映射 |
| 利率参数 | 分散在产品表、账户表 | 条件级利率表 | 归位并建立档期 |
| 客户协议 | 隐含在账户属性中 | 独立客户级协议 | 提取协议并关联 |
| 渠道限额 | 渠道系统单独维护 | 产品级渠道参数 | 迁移并校验冲突 |
| 特殊交易 | 专用交易码 | 标准组件+例外 | 列入例外清单 |
理解新核心架构与产品工厂理念，是参数迁移从“搬数据”升级为“重建产品行为”的前提。只有把旧核心的隐含逻辑显式化、把分散参数归位到正确层级，才能在新核心中还原出可验证、可维护的产品参数体系。