DM-02｜客户与业务关系领域模型

状态：working-draft；候选模型，不是已锁定的结构或状态契约。
上游：BC-02；输入：旧聚合材料（历史材料保留在 docs_bak/）。
编写：主会话；业务决策与长期维护人：待指定。日期：2026-09-18。

1. 对象分类与候选聚合

对象	分类	维护什么	要保护的业务含义
CustomerProfile	候选根	客户基础关系与状态	Customer 不等于 Account
SavedAddress	候选根	单地址及验证依据	更新不修改订单快照
ConsentHistory / Restriction	历史事实及候选独立根	用途同意历史；单项限制	有效同意是派生结果，不删除历史伪造授权
PersonalRecipe / WeeklyMealPlan	候选根	个人菜谱；计划版本与餐次编排	只引用商品内容；计划不包含权威成交价格
MealOccurrence / PurchaseReference	稳定餐次实体 / 关联引用	日期餐次、编辑版本、历次购买与后继单引用	同餐次可关联多次合法购买；不能凭用户+日期唯一化订单
GroupLeaderProfile / GroupCampaign	候选独立根	资格协议；活动及参与规则	团长活动不拥有订单与支付
CustomerCase	候选根	服务事项与处理责任	不是交易售后裁决
Customer360	组合投影	各域最小化摘要	不能反向写各域事实

“候选根”表示需要独立身份、生命周期及一致性责任的提案，不代表每行已经确定为一个事务。历史、子实体、值对象及集合的最终边界还需基于规模和不变量核对。

客户引用 Person；地址、同意、计划通过 CustomerId 关联；个人计划引用 Catalog 版本；订单保存本次接受的地址/计划来源快照。单独查询和更新频繁的历史集合不无限挂在客户根。

餐次编辑只改变意图。正式换菜由 Commerce 接受明确替换请求，原单/后继单通过稳定餐次关联；取消/到期的订单不因计划再次出现相同菜名而复活。删除餐次不直接取消交易或释放资金。引用交易级严谨性；周计划不是订阅或钱包。

值对象及共享引用的统一含义见 MODELING-RULES。上下文之间引用 ID、版本或不可变快照，不共享可变实体。

地址：待验证 → 已确认或待修正；同意：授予 / 撤回形成历史，当前结果按用途与版本派生；团长资格、活动、客户限制各自有生命周期，不能共用 customer.active。

这些是语义级路径，尚未列全每种政策下的迁移；不能直接生成生产枚举。业务对象状态、协调进度和技术回执分别保存与展示。

顾客维护本人地址与计划；客服基于用途读取或处理服务事项；资格审批按角色范围执行。事件候选：“地址已确认”“同意已撤回”“团长资格已变更”，不携带无关敏感字段。

事件名称为中文业务语义候选，不新建机器事件名。进入后续契约设计时逐项确定输入、前置条件、结果、错误和受众。

若要求唯一默认地址，需客户级地址选择守卫或独立 DefaultAddress 关系，单个 SavedAddress 版本不足；用途/隐私同意变更与传播记录应一致，跨消费者清理用可追踪流程；该同意不是Demand的本次配送ConfirmationRecord，不直接取消或确认配送。

共同约束见 CONSISTENCY：单根版本不能替代跨对象约束；如需同 BC 多根本地事务，必须明确保护范围与理由，不能默认为整个 BC 一把锁。

两个地址同时设默认；撤回后排队导出；客户合并部分完成；计划更新不改订单。默认地址规则、合并策略、保留依据与增长归因 Owner 仍待定。

上述反例是设计验证目标，尚未执行产品测试。先关闭影响边界的不确定性，再完善动作级迁移表及精确模型。身份、权限与业务状态的联动仍遵守 07 的统一授权接缝，不在本页复制一套权限规则。