DDD
领域驱动设计。用业务语言给系统建模，让代码结构直接反映业务边界。
又称领域驱动设计Domain-Driven Design
架构
是什么
DDD（Domain-Driven Design）是一套以业务领域为中心的软件建模方法。它要求开发人员和领域专家共用一套语言（统一语言），并把这套语言直接写进代码：类名、方法名、包结构都用业务术语，而不是 UserManager、DataHandler 这类技术词汇。
战略设计与战术设计
- 战略设计：划分子域（核心域、支撑域、通用域），用限界上下文界定模型边界，定义上下文之间的集成关系。
- 战术设计：在限界上下文内部落地模型——聚合根 、实体、值对象、领域服务、仓储、领域事件。
在银行核心系统里怎么用
银行核心的复杂度不在技术，而在业务规则的组合爆炸：客户类型 × 账户类型 × 产品 × 监管要求。DDD 的价值是把这些规则收敛进领域模型，而不是散落在几千个 SQL 和 if-else 里。
实践中最容易翻车的点是：把 DDD 当成「分层架构」来用，画了四层目录却没做过限界上下文划分——那只是换了名字的三层架构。
提及本词的文章
- 聚合根与领域事件：DDD 战术建模从一致性边界到事件驱动，拆解聚合根的设计原则、领域事件的发布与消费，以及在银行核心系统里的落地坑点。
- 《领域驱动设计》读书笔记重读 Evans 这本书之后的笔记：真正有价值的是前四章的思维方式，而不是后面那堆模式清单。
- DDD 在银行核心系统的落地实践从限界上下文切分到聚合设计，记录 DDD 在银行核心系统改造中真正有用的部分与真正无效的部分。
- 开博第一篇：为什么写「追风笔记」记录我做银行系统架构这些年的思考，以及这个站点的由来。
- 关于专注分布式核心系统与银行业务，探索 AI 在银行领域的落地。