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

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

## 1. 对象分类与候选聚合

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

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

## 2. 关系与引用

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

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

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

## 3. 生命周期

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

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

## 4. 业务动作与事件

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

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

## 5. 强一致性及并发边界

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

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

## 6. 反例、未知与下一步

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

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