https://0607501b.wangpeng.pages.dev/Recent content on 追风笔记HugozhSat, 15 Aug 2026 00:00:00 +0000https://0607501b.wangpeng.pages.dev/about/bio/Mon, 01 Jan 0001 00:00:00 +0000https://0607501b.wangpeng.pages.dev/about/bio/<h2 id="我是谁">我是谁</h2> <p>王鹏，数学学士 + 计算机硕士，现就职于某银行总部（北京），担任后端架构师。</p> <p>日常工作围绕<strong>客户信息系统（ECIF）</strong>、<strong>核心系统</strong>与<strong>分布式系统</strong>展开，熟悉：</p> <ul> <li>分库分表、RocketMQ 动账通知；</li> <li>账户 / 卡 / 支付结算 / 计息 / 限额；</li> <li>数据治理与安全加密；</li> <li>支付系统（二代支付、银联 / 网联）；</li> <li>反洗钱 / KYC / CRS。</li> </ul> <h2 id="我在做什么">我在做什么</h2> <ul> <li>目标：从银行技术专家走向 CIO；</li> <li>同时经营个人品牌第二曲线——公众号「金融科技百分百」，写银行系统、金融科技、支付、分布式与 IT 架构；</li> <li>这个站点（追风笔记）是我沉淀技术专栏、博客与文档的地方。</li> </ul>https://0607501b.wangpeng.pages.dev/about/writing/Mon, 01 Jan 0001 00:00:00 +0000https://0607501b.wangpeng.pages.dev/about/writing/<p>我在这个站点上主要写三类专栏，对应我在银行工作中的不同关注点：</p> <ul> <li><a href="https://0607501b.wangpeng.pages.dev/architecture/">架构专栏</a>：客户信息系统、核心系统、分布式架构与 DDD；</li> <li><a href="https://0607501b.wangpeng.pages.dev/banking/">银行业务专栏</a>：支付清算、计息与限额、账户 / 卡、反洗钱（AML）/ KYC / CRS；</li> <li><a href="https://0607501b.wangpeng.pages.dev/data/">数据专栏</a>：数据治理、加密与安全、分库分表、消息与流处理。</li> </ul> <p>此外，我也在运营公众号「金融科技百分百」，分享银行系统、金融科技、支付、分布式与 IT 架构相关的实战与思考。</p>https://0607501b.wangpeng.pages.dev/about/contact/Mon, 01 Jan 0001 00:00:00 +0000https://0607501b.wangpeng.pages.dev/about/contact/<ul> <li>公众号：金融科技百分百</li> <li>邮箱：（待补充）</li> </ul>https://0607501b.wangpeng.pages.dev/blog/welcome/Sat, 15 Aug 2026 00:00:00 +0000https://0607501b.wangpeng.pages.dev/blog/welcome/<p>做银行系统架构这些年，踩过的坑、想明白的事，大多散落在笔记本和聊天记录里。开这个站点，是想把它们系统地沉淀下来。</p> <h2 id="我会写什么">我会写什么</h2> <ul> <li><strong>架构专栏</strong>：客户信息系统（ECIF）、核心系统、分布式架构，以及领域驱动设计（DDD）在银行场景下的落地。</li> <li><strong>银行业务专栏</strong>：支付清算、计息与限额、账户/卡、反洗钱（AML）/KYC/CRS 等核心业务梳理。</li> <li><strong>数据专栏</strong>：数据治理、加密与安全、分库分表、消息与流处理。</li> </ul> <h2 id="写给谁">写给谁</h2> <p>同行、想转行做金融科技的工程师，以及任何对「银行系统为什么这么设计」感到好奇的人。</p> <blockquote> <p>这个站点是示例内容，框架搭好后，真实文章会逐步替换进来。</p> </blockquote>https://0607501b.wangpeng.pages.dev/architecture/ddd-aggregate/Wed, 12 Aug 2026 00:00:00 +0000https://0607501b.wangpeng.pages.dev/architecture/ddd-aggregate/<p>ECIF 里「客户」的概念极其庞大：个人、对公、同业，各自的属性、关系、生命周期都不同。如果用一个巨大的 <code>Customer</code> 实体硬扛，代码会迅速腐化。</p> <h2 id="用界限上下文切分">用界限上下文切分</h2> <p>把客户拆成几个界限上下文：</p> <ul> <li><strong>客户主数据（Party）</strong>：统一的自然人/机构标识与基础属性。</li> <li><strong>客户画像（Profile）</strong>：风险偏好、营销标签，读写频率高、变化快。</li> <li><strong>客户关系（Relationship）</strong>：持股、担保、集团关系。</li> </ul> <h2 id="聚合根怎么定">聚合根怎么定</h2> <p>每个上下文内部再定聚合根。例如 Party 上下文里，<code>Party</code> 是聚合根，<code>Address</code>、<code>Contact</code> 是其值对象，保证一致性边界内不跨聚合调用。</p> <blockquote> <p>经验：聚合的边界应以「事务一致性」而非「业务概念大小」来划。ECIF 里最容易犯的错，就是把所有客户信息塞进一个聚合。</p> </blockquote> <p>这样设计后，主数据服务稳定，画像服务可以独立迭代，互不影响。</p>https://0607501b.wangpeng.pages.dev/banking/ecif-overview/Mon, 10 Aug 2026 00:00:00 +0000https://0607501b.wangpeng.pages.dev/banking/ecif-overview/<p>在没有 ECIF 的年代，网点、网银、信用卡中心各自维护一份客户信息。同一个客户，在不同系统里姓名、证件、联系方式都不一样，营销和风控都无从谈起。</p> <h2 id="ecif-解决什么">ECIF 解决什么</h2> <p>ECIF（企业客户信息整合）把分散在各业务系统的客户主数据收敛到一处，对外提供<strong>唯一客户视图</strong>。</p> <ul> <li><strong>唯一标识</strong>：用客户号（Party ID）统一自然人/机构，而非证件号。</li> <li><strong>主次关系</strong>：支持一人多户、一户多卡，但主数据唯一。</li> <li><strong>服务化</strong>：其他系统通过接口查询，不再各自落库。</li> </ul> <h2 id="技术上的关键取舍">技术上的关键取舍</h2> <ul> <li><strong>读写分离</strong>：主数据写入强一致，查询可走缓存/只读副本。</li> <li><strong>变更可溯源</strong>：客户信息变更需要留痕，满足监管审计。</li> </ul> <blockquote> <p>ECIF 不是「又一个数据库」，而是银行数字化的最底层地基。</p> </blockquote>https://0607501b.wangpeng.pages.dev/data/data-governance/Sat, 08 Aug 2026 00:00:00 +0000https://0607501b.wangpeng.pages.dev/data/data-governance/<p>很多银行的数据治理项目最后沦为「补元数据、填责任表」。要见效，得把治理内建到数据生产的流水线里。</p> <h2 id="两件事优先做">两件事优先做</h2> <ul> <li><strong>元数据与血缘</strong>：字段从哪个系统来、被哪些任务加工、流向哪里，必须可自动追踪。</li> <li><strong>质量规则内建</strong>：非空、唯一、口径一致等校验，在 ETL/湖仓任务里当「门禁」，不过不入库。</li> </ul> <h2 id="安全与加密">安全与加密</h2> <ul> <li><strong>静态加密</strong>：落盘即对敏感字段加密（如证件号、卡号）。</li> <li><strong>动态脱敏</strong>：查询侧按角色脱敏，开发环境拿不到明文。</li> </ul> <blockquote> <p>治理的目标不是「漂亮的报告」，而是让 downstream 系统敢用这份数据。</p> </blockquote>