BC-02｜客户与业务关系（customer）

状态：working-draft；本次边界建议，未批准为完整新基线。
Design=draft；Contract=not-defined-here；Implementation=not-assessed；Verification=document-review-only。
上游：SD-02（仍为候选占位）
输入：既有模块设计（历史材料保留在 docs_bak/）
编写责任：主会话；业务决策 / 长期维护责任人：待指定。日期：2026-09-18。

1. 需要什么，它是什么

持续识别服务对象，维护客户资料、同意、服务关系与团长参与。

统一语言：Customer 是与鼎味的业务关系；SavedAddress 是可变地址簿；CustomerCase 是服务沟通事项，不等同于交易售后裁决。

一周无忧的 WeeklyMealPlan / MealOccurrence 属于个人生活安排，保存稳定餐次、编辑版本和历次购买引用；不是订阅合同、订单或资金余额。换菜时用户沿餐次连续查看，但已成交内容由 Commerce 的原单/后继单表达，不能通过编辑计划回写订单。见交易级严谨性。

2. 拥有与不拥有

拥有： 客户档案、联系点、地址簿、同意与偏好、限制、个人菜谱与周计划、客户服务事项、团长资格协议与活动关系。

不拥有： 登录凭证；订单成交地址及价格快照；订阅合同；商品推荐内容；售后退款裁决；外部平台买家原始记录。

这里列出事实族和职责，不直接定义数据库表、聚合事务范围或最终接口名称；详细模型须在下一层继续验证。

3. 谁参与，怎样使用

顾客维护本人资料和计划；团长管理授权关系；客服通过后台按用途查看资料；Commerce、Demand、Fulfillment 获取必要引用或快照。

典型场景：顾客修改地址簿 → 后续交易重新取用并校验；既有订单保持原快照。客服发现交易争议 → 关联 Commerce 售后事项，不在客户服务页直接退款。

4. 如何与其他上下文协作

从 Identity 引用稳定主体标识；向交易提供地址/资格/计划版本；个人计划引用 Catalog 内容。隐私撤回向有关消费者传播并跟踪处理结果。

调用方向、信息方向、流程协调者和失败责任统一见 CONTEXT-MAP；事实边界及混淆项见 OWNERSHIP。不使用共享可变实体或跨 Owner 写表。

5. 不变量、权限与一致性

客户合并不等于账号合并；地址更新不回写订单；PII 按用途与字段最小化；客户摘要不能成为跨域写入口。

所有入口遵循 统一授权接缝。本上下文负责自己的资源关系和业务动作条件，不能仅凭客户端提交的角色或对象归属放行。

6. 失败、并发与恢复

并发资料变更需版本检查；合并跨域引用失败保留可恢复进度；撤回同意不删除必须保留的交易事实，其保留政策不得自行设定。

部署和数据库共用不构成跨上下文原子性承诺。需要立即成立的约束在对应事实 Owner 内执行；跨域步骤记录意图、版本、结果与恢复进度。

7. 边界取舍与可能推翻结论的证据

与 Identity 分离。团长资格暂与客户关系同属 Customer；增长归因、佣金和实验若形成独立规则，不能借“关系”二字无限纳入，见 BOUNDARY-DECISIONS。

反证检查：验证改地址后旧订单不变、两账号不因手机号相同自动合并、客服 Case 关闭不伪造退款成功、撤回同意后异步消费者不继续使用旧授权。

上述是设计反例清单，尚未执行产品测试。拆合讨论及重开条件见 BOUNDARY-DECISIONS。

8. 未决事项与后续交付

团长业务深度、归因事实 Owner、合并与保留政策、推荐决策归属尚需收敛。

先核对本页业务范围及上下文边界，再细化模型、不变量、状态、命令/查询/事件和授权契约；最后派生完整业务增量 REQ。不得据本稿直接锁定开发接口。当前未决项统一归入DECISIONS对应D项；REVIEW仅保留历史审查及Q项来源，不另作活动决策台账。