标签: 银行核心

核心系统的模型看起来很朴素：账户、余额、交易、分录。真正做进去才发现，每一个概念背后都有一堆不能妥协的约束，而这些约束在需求文档里往往一个字都没写。这篇是零散的建模笔记，按我认为重要性排的顺序。 核心系统到底在建模什么 先把定位说清楚。核心系统建模的对象不是"业务流程"，而是会计事实。 客户在手机上点一下转账，这是渠道行为；反洗钱要不要拦、限额够不够，这是风控与协议判断；而核心真正负责的只有一件事：在正确的会计日，把一组借贷平衡的分录准确地记下来，并保证余额永远等于分录累计的结果。 想清楚这一点 …

银行核心最痛的不是业务复杂，而是业务逻辑和周边技术死死绑在一起：换连接池要改核心，接新渠道要动账务，单测要起一整套中间件。六边形架构（Ports & Adapters）给出干净解法。 核心、端口与适配器 领域核心：纯业务规则，不依赖任何框架、数据库或 HTTP 客户端。 端口：核心暴露（入站）和需要（出站）的接口，用 Java 接口表达意图。 适配器：把端口接到具体技术——REST 控制器是入站适配器，JDBC 仓储是出站适配器。 public interface …

单元化被讲成"异地多活的银弹"，但它真正解决的问题只有两个：把故障爆炸半径收进一个单元，以及让容量可以按单元横向叠加。理解不了这两点，做出来的往往只是一套更复杂的分库分表。 为什么核心要做单元化 传统主备架构的困境是：备机平时不承载流量，切换时没人敢按那个按钮。因为没人验证过备机在真实压力下能不能扛住。 单元化把这件事变成常态：每个单元都在真实处理流量，每个单元都是完整的业务闭环——接入层、应用层、数据库全套齐备。某个单元挂了，把它的流量按客户维度切到其他单元，其他单元本来就在跑同样的代码和同样 …

银行核心系统是一类很特殊的软件：它的业务规则几十年没怎么变，但承载它的代码每隔七八年就要重写一次。我参与过一次核心的部分重构，也旁观过一次彻底失败的重写。DDD 在这两次里都被提过，但只有一次真的起了作用。这篇把我认为有效的部分和纯属自我感动的部分分开写。 为什么银行核心需要 DDD 老核心的问题从来不是技术栈老。COBOL 写的联机交易照样能扛住每秒几千笔。真正的问题是：业务知识只存在于少数几个人的脑子里，代码里找不到对应的表达。 一段典型的老代码长这样：把交易码、账户类型、产品编号、机构号混 …