专栏
围绕工作主线系统整理的系列专栏，按主题深入展开。
专栏
围绕工作主线系统整理的系列专栏，按主题深入展开。
这里是按主题整理的专栏入口。每个专栏围绕一条工作主线展开，把相关文章串成可长期查阅的知识脉络。
目录
架构专栏
客户信息系统、核心系统、分布式架构与领域驱动设计（DDD）的实战拆解。
银行系统的复杂度，往往不在单点技术，而在「如何把监管、账务、渠道与性能约束织成一张自洽的网」。本专栏拆解其中的关键决策与权衡。
下面是本专栏的文章：
在银行客户信息系统（ECIF）里落地 DDD 聚合
客户是「一个实体」还是「一组上下文」？用聚合根与界限上下文重新切分 ECIF 的客户模型。
ECIF 里「客户」的概念极其庞大：个人、对公、同业，各自的属性、关系、生命周期都不同。如果用一个巨大的 Customer 实体硬扛，代码会迅速腐化。
用界限上下文切分
把客户拆成几个界限上下文：
- 客户主数据（Party）：统一的自然人/机构标识与基础属性。
- 客户画像（Profile）：风险偏好、营销标签，读写频率高、变化快。
- 客户关系（Relationship）：持股、担保、集团关系。
聚合根怎么定
每个上下文内部再定聚合根。例如 Party 上下文里，Party 是聚合根，Address、Contact 是其值对象，保证一致性边界内不跨聚合调用。
经验：聚合的边界应以「事务一致性」而非「业务概念大小」来划。ECIF 里最容易犯的错，就是把所有客户信息塞进一个聚合。
这样设计后，主数据服务稳定，画像服务可以独立迭代，互不影响。
银行业务专栏
支付清算、计息与限额、账户/卡、反洗钱（AML）/KYC/CRS 等银行核心业务梳理。
银行的「业务规则」才是系统真正的复杂度来源。本专栏把核心业务从底层机制讲起，让技术决策有业务依据。
下面是本专栏的文章：
一文理清 ECIF：客户信息为什么要「集中」
从多头开户、信息不一致到统一客户视图，ECIF 解决的是银行最基础的「客户是谁」问题。
在没有 ECIF 的年代，网点、网银、信用卡中心各自维护一份客户信息。同一个客户，在不同系统里姓名、证件、联系方式都不一样，营销和风控都无从谈起。
ECIF 解决什么
ECIF（企业客户信息整合）把分散在各业务系统的客户主数据收敛到一处，对外提供唯一客户视图。
- 唯一标识：用客户号（Party ID）统一自然人/机构，而非证件号。
- 主次关系：支持一人多户、一户多卡，但主数据唯一。
- 服务化：其他系统通过接口查询，不再各自落库。
技术上的关键取舍
- 读写分离：主数据写入强一致，查询可走缓存/只读副本。
- 变更可溯源：客户信息变更需要留痕，满足监管审计。
ECIF 不是「又一个数据库」，而是银行数字化的最底层地基。
数据专栏
数据治理、加密与安全、分库分表、消息与流处理相关的技术与方法论。
数据是现代银行的资产，也是风险。本专栏关注「让数据可用、可信、可控」的工程实践。
下面是本专栏的文章：
银行数据治理：先治「元数据」再治「质量」
数据治理常被当成填表运动，真正的抓手是元数据血缘与质量规则内建到流水线里。
很多银行的数据治理项目最后沦为「补元数据、填责任表」。要见效，得把治理内建到数据生产的流水线里。
两件事优先做
- 元数据与血缘：字段从哪个系统来、被哪些任务加工、流向哪里，必须可自动追踪。
- 质量规则内建：非空、唯一、口径一致等校验，在 ETL/湖仓任务里当「门禁」，不过不入库。
安全与加密
- 静态加密：落盘即对敏感字段加密（如证件号、卡号）。
- 动态脱敏：查询侧按角色脱敏，开发环境拿不到明文。
治理的目标不是「漂亮的报告」，而是让 downstream 系统敢用这份数据。