多限界上下文内实体共用同一身份的问题及Customer案例困惑

核心问题拆解 #

你疑惑的核心点在于：为何其他限界上下文（BC）不能将同一身份的概念作为带专属属性的实体，而只能以只读值对象或ID形式存在？

多BC中存储同一身份实体的潜在问题 #

• 数据一致性风险：若多个BC都维护同一身份下的专属属性，一旦源BC中核心身份信息（如用户状态、基础标识）变更，其他BC的实体无法自动同步，会出现数据割裂。比如源BC标记Customer为「禁用」，但订单BC内的Customer实体仍显示「活跃」，直接导致业务逻辑错误。
• 职责边界模糊：每个BC的核心是处理自身领域的业务逻辑，若在BC内维护Customer的专属配置，本质是将用户管理的职责分散到多个BC，违背了限界上下文「围绕核心业务能力划分」的定义，也打破了单一职责原则。
• 协作复杂度飙升：当需要修改Customer的身份规则时，需遍历所有存储该实体的BC做适配，维护成本指数级增长；跨BC的实体操作还需依赖分布式事务或复杂事件同步机制，大幅提升系统复杂度。

对限界上下文定义的澄清 #

你提到的「不同领域表示同一现实身份，仅保留相关行为和属性」是正确的，但这里的「表示」并非在每个BC都创建带身份的实体，而是基于源BC提供的身份数据，在本地构建只读视图（值对象），再单独存储BC专属的配置。

举个具体例子：

• 源BC：CustomersManagement，作为Customer的唯一数据源（System of Record），维护核心身份数据（ID、姓名、状态、联系方式）。
• 订单BC：无需存储Customer实体，只需保留CustomerId（身份标识）+ 本地专属的CustomerOrderConfig（如用户的订单自动签收设置、偏好配送时间）——这个CustomerOrderConfig是订单BC内部的实体，仅和源BC的Customer通过ID关联，并非同一概念。

更合理的实践方案 #

采用单一CustomersManagement BC作为Customer核心身份的唯一数据源，其他BC按以下方式处理：

1. 只读值对象同步：通过领域事件（如CustomerCreated、CustomerUpdated）将核心属性同步到其他BC，作为只读值对象用于展示或业务规则校验。
2. 本地专属配置单独存储：每个BC的用户专属配置，作为BC内部的实体/值对象存储，通过CustomerId与源BC的身份关联，既保证核心身份数据一致性，又保留各BC的业务灵活性。
3. 按需调用源BC：若需实时获取Customer的核心状态，直接调用CustomersManagement BC的查询接口，避免本地缓存过期引发的问题。

内容的提问来源于stack exchange，提问作者CliffhAnger