银行核心系统建模随笔

Sun, 02 Aug 2026 00:00:00 +0000

核心系统的模型看起来很朴素：账户、余额、交易、分录。真正做进去才发现，每一个概念背后都有一堆不能妥协的约束，而这些约束在需求文档里往往一个字都没写。这篇是零散的建模笔记，按我认为重要性排的顺序。

核心系统到底在建模什么

先把定位说清楚。核心系统建模的对象不是"业务流程"，而是会计事实。

客户在手机上点一下转账，这是渠道行为；反洗钱要不要拦、限额够不够，这是风控与协议判断；而核心真正负责的只有一件事：在正确的会计日，把一组借贷平衡的分录准确地记下来，并保证余额永远等于分录累计的结果。

想清楚这一点，很多设计争论会自动消失。比如"转账的营销活动规则要不要放核心"——不放，那不是会计事实。核心的表越少越好，能力越单一越好。

判断一个需求该不该进核心，只问一句：它会改变账务事实吗？不会，就放外围。核心系统膨胀的过程，就是这条边界一次次让步的过程。

账户模型：一棵不能长歪的树

账户号不是主键

这是我见过最多的建模错误。账号是业务标识，有格式规则、会变更、会重开、可能因迁移换号段。用它做物理主键，等到某天要做账号升位或者跨行并库，整个系统的外键关系会一起爆炸。

正确做法是内部 ID 与业务账号分离：

public class Account {
 private final AccountId id; // 内部标识，永不变更，不对外暴露
 private AccountNo accountNo; // 业务账号，可变更，对外展示
 private final CustomerId owner;
 private final ProductCode product;
 private final Currency currency;
 private AccountStatus status;
 private final LocalDate openDate;

 /** 账号变更保留历史，因为凭证和流水引用的是历史账号 */
 public void changeAccountNo(AccountNo newNo, String reason) {
 if (status != AccountStatus.ACTIVE) {
 throw new DomainException("非正常状态账户不允许换号");
 }
 registerEvent(new AccountNoChanged(id, accountNo, newNo, reason));
 this.accountNo = newNo;
 }
}

AccountNoChanged 事件必须落库。半年后有人拿旧账号来查流水，你要能翻译过去。

账务 on 追风笔记

银行核心系统建模随笔

核心系统到底在建模什么

账户模型：一棵不能长歪的树

账户号不是主键