https://0607501b.wangpeng.pages.dev/categories/%E6%9E%B6%E6%9E%84/Recent content in 架构 on 追风笔记HugozhWed, 12 Aug 2026 00:00:00 +0000https://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>