领域建模 on 追风笔记

银行核心系统建模随笔

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 事件必须落库。半年后有人拿旧账号来查流水，你要能翻译过去。

《领域驱动设计》读书笔记

Tue, 14 Apr 2026 00:00:00 +0000

这本书我读过三遍。第一遍在工作两年时，只记住了实体、值对象、聚合这几个名词；第二遍在做核心重构时，才发现前面几章才是重点；第三遍是带团队时读的，读出来的东西又不一样。

这本书真正的价值

大部分人把它当模式手册用，翻到"聚合"那一节抄个定义就开始设计。但 Evans 花了整本书篇幅想说的其实是一件事：软件设计的瓶颈是知识，不是技术。

模型不是画出来的，是在和业务专家反复对话中"长"出来的。书里那些模式只是长出来之后用于表达的工具。工具本身不产生知识。

一个团队如果没有和业务专家持续对话的机制，那么它用不用 DDD 的模式都无所谓——反正模型里没有真正的领域知识。

我划重点的三处

第一是统一语言。 这是全书性价比最高的概念，也最容易被跳过。如果业务方说"客户"指的是签约主体，而代码里的 Customer 指的是自然人，那么所有后续设计都建立在一个错位的基础上。我们后来的做法很土：维护一份术语表，中英文对照，明确写出每个词的边界和不包含什么。上线一年下来，它减少的沟通成本比任何架构决策都多。

第二是模型驱动设计的"绑定"要求。 书里强调模型和实现必须绑死——模型改了代码就得改，代码改了模型文档也得改。做不到这一点，模型就退化成挂在墙上的装饰。这也是为什么我不再维护单独的模型图，而是让代码本身成为模型的唯一表达：

// 反例：技术化命名，业务方看不懂，术语在翻译中丢失
public class RuleProcessor {
 public BigDecimal calc(BigDecimal amt, BigDecimal r, int type) { }
}

// 正例：类名与方法名直接采用统一语言中的业务术语
// accrual（计提）不简化成 calc，basis（计息基础）不省略
public class InterestAccrualRule {
 public Money accrue(DailyBalance balance, Rate rate, DayCountBasis basis) { }
}

第三是"深层模型"和重构的关系。 书里说好模型需要经历多次突破，而突破往往来自某次对业务的重新理解。这一点我深有体会：我们的账务模型是在第三次重写时才想清楚"分录是第一公民、交易只是外壳"，前两版都是围着交易类型打转。第一次就设计出好模型的期待本身就不现实。

读完之后我改了什么

需求评审改成建模会。不再让业务方念文档，而是当场画概念、当场确认术语。
术语表进代码仓库。放在 docs/glossary.md，跟代码一起评审，改术语要走 PR。
不再追求完整套用模式。战术模式里我们只常用值对象和聚合，事件溯源、CQRS 一律不用，除非有明确的读写比例失衡问题。
接受模型会被重写。第一版模型的目标是能跑并暴露问题，不是一次做对。

如果只有两小时读这本书，我建议读第一部分和第三部分的第 8 章（突破），跳过所有模式定义。模式的定义随便搜一下都有，而"如何通过对话获得领域知识"这件事，只有认真读原文才能体会到。

DDD 在银行核心系统的落地实践

Mon, 12 Jan 2026 00:00:00 +0000

银行核心系统是一类很特殊的软件：它的业务规则几十年没怎么变，但承载它的代码每隔七八年就要重写一次。我参与过一次核心的部分重构，也旁观过一次彻底失败的重写。DDD 在这两次里都被提过，但只有一次真的起了作用。这篇把我认为有效的部分和纯属自我感动的部分分开写。

为什么银行核心需要 DDD

老核心的问题从来不是技术栈老。COBOL 写的联机交易照样能扛住每秒几千笔。真正的问题是：业务知识只存在于少数几个人的脑子里，代码里找不到对应的表达。

一段典型的老代码长这样：把交易码、账户类型、产品编号、机构号混在一个几百行的过程里，用几十个 IF 分支区分场景。你想知道"活期账户计息到底怎么算"，只能从头读到尾，然后祈祷没漏掉某个补丁分支。

代码可以重写，业务知识不能。重构核心系统的第一目标不是换语言，而是把散落在分支里的规则重新变成可以被讨论的概念。

这正是 DDD 唯一真正值得投入的地方：它提供了一套让业务专家和工程师用同一套词汇讨论问题的方法。别的都是附加品。

战略设计：先切限界上下文

如果只能做 DDD 的一件事，就做上下文切分。这一步做错，后面所有战术模式都是白费。

以业务能力而非表结构切分

最常见的错误是按数据库表切：账户表归账户服务，交易表归交易服务。结果是每笔转账都要跨三个服务改数据，分布式事务满天飞。

我们最后落在这几个上下文上：

客户与关系：客户主体、关系人、证件、KYC 状态
账户与协议：账号、账户属性、签约关系、限额协议
交易处理：交易受理、要素校验、路由、冲正
账务核算：分录、余额、总账、日终结转
产品参数：利率、费率、期限、计息规则

关键判据是：一次业务动作的强一致性要求是否落在同一个上下文内。转账的"扣款成功且分录平衡"必须强一致，所以账务核算不能再往下拆；而"转账成功后更新客户活跃度"完全可以最终一致，那就是两个上下文。

上下文映射的三种常见关系

关系类型	银行场景举例	集成方式	注意点
共享内核	账户上下文与账务上下文共用币种、金额模型	公共 jar，严格版本管理	只放值对象，禁止放业务逻辑
客户方-供应方	交易处理调用账务记账	同步 RPC，供应方定契约	契约变更必须双版本并行
防腐层	新模块访问老核心账户查询	适配器 + 模型转换	老模型绝不允许穿透进来

一个反例

我们曾经把"限额"单独切成一个上下文。听起来很干净，实际上限额校验必须和交易受理在同一个事务里完成，跨服务调用一下就把联机响应时间从 40ms 拖到 90ms，还引入了新的失败分支。半年后合并回交易处理上下文。

上下文边界的正确性，用一致性要求和调用频次验证，不用概念优雅度验证。

战术落地：聚合、实体与值对象

战术模式在核心系统里的价值远低于战略设计，但用对了确实能减少一批低级 bug。

聚合的粒度取决于一致性边界

账务这块我们的聚合是"分录凭证"（Voucher），不是"账户"。一张凭证包含多条分录，借贷必须平衡，这是不可分割的一致性单元。账户余额是凭证记账的结果，通过事件更新。