上下文关系与协作责任
状态：working-draft；能力语义级关系，不新增正式 API / Event / Process 名称。
日期：2026-09-18；上游：候选上下文。
1. 信息方向与调用方向分别表达
以下图中箭头仅表示“事实或决策输入由谁提供给谁”，不是网络调用顺序，也不是全部依赖清单。详细命令调用方向见下表。
flowchart LR
Catalog[商品与发布] -->|规格版本| Commerce[交易与资金售后]
Customer[客户关系] -->|资格和快照来源| Commerce
Supply[供给质量追溯] -->|供给能力| Demand[预约承诺与订阅]
Fulfillment[履约交付] -->|履约能力| Demand
Demand -->|承诺结果和周期意图| Commerce
Commerce -->|确认订单| Fulfillment
Customer -->|餐次意图不是成交| Commerce
Demand -->|每日明确授权及版本| Fulfillment
Fulfillment -->|现场观察| Supply
Supply -->|物料和质量决定| Fulfillment
Channel[外部渠道] -->|经适配观察| Commerce
Commerce -->|经济事实| Finance[财务核算]
Finance -->|核算事实| Analytics[经营分析]
Commerce -->|交易事实| Analytics
Identity[身份授权] -.->|统一授权决策| Commerce
Identity 面向所有 BC，Analytics 按权限消费各事实 Owner，Platform 提供可靠传输，图中只画代表边以保持可读。小程序、后台、作业端在统一入口调用应用能力，不作为业务 BC 节点。
| 能力提供者 | 调用者 / 消费者 | 消费者 → 提供者的请求 | 提供者 → 消费者的数据 | 接缝约束 |
|---|---|---|---|---|
| Identity | 全部入口及 BC | 认证、授权和有效范围查询 | 主体上下文及版本化决定 | 业务 Owner 提供可信对象关系；不信任客户端自报归属 |
| Customer | Commerce / Demand / 合法履约查询 | 查询客户资格、地址、计划与同意 | 最小化引用或版本快照 | 历史承诺不追随地址簿变更；PII 用途限定 |
| Catalog | Commerce / Demand / Supply / Fulfillment / Channel | 查询发布版本及规格 | 不可变规格与发布结果 | 下游转换成自己的快照，不共享可变 Product |
| Supply | Demand | 读取/订阅供给能力 | 版本、时点与质量相关能力 | 过期不能默认充足 |
| Fulfillment | Demand | 读取/订阅履约能力 | 版本化履约能力 | Demand 不改源能力 |
| Demand | Commerce / 已登记渠道或周期流程 | 申请、确认、释放及改期 | Hold / Commitment / 冲突结果 | 所有命令经 Owner；不跨库扣容量 |
| Commerce | Demand 周期流程 / Channel | 请求标准订单、查询来源结果 | 同一来源及被接受拆分范围的订单结果集合与协调进度 | 同来源重试返回原结果；不强定一来源一单，也不把其他入口强塞顾客即时结算流程 |
| Fulfillment | Commerce 协调流程 | 接收确认结果、请求停止或变更 | 接收件、停止结果及执行进度 | 停止请求不等于已经停止，已发生动作不能删 |
| Supply | Fulfillment 执行流程 | 请求分配、记录转换、绑定包裹 | 物料与追溯结果 | 任务与物料双向协作不是共享事务 |
| Commerce / Fulfillment / Demand / Customer | Supply 召回流程 | 处理各自受影响业务 | 分项回执和待处置结果 | Supply 协调召回但不直接退款或修改任务 |
| 业务事实 Owner | Channel | 导入观察或回传所需查询 | 内部接受/拒绝结果和业务进度 | 外部状态经防腐转换，不写内部表 |
| Commerce；启用的 Supply/Fulfillment/Channel 来源 | Finance | Finance 接收来源或查询校验 | 具有来源身份的经济事件 | 观察、验证与会计解释分层；防重复来源 |
| 各 BC、Finance | Analytics | 受控事件消费与回源核验 | 事实变更、来源版本 | 分析修复不反向改源事实 |
| 各源系统、BC及Analytics | Platform监控接入/检测器 | 受控观察订阅、回源查询和质量核验 | 带身份、版本、时间、质量的信号及证据 | 通用内核不含业务分支；Analytics不是所有实时检测的必经节点 |
| 已登记动作的源Owner | Platform自动化执行器 | 带原目标、版本、授权和幂等身份的受限命令/查询 | 受理、确定结果或UNKNOWN及验收证据 | 源Owner重验门禁；执行ACK不等于恢复，平台不得直写源表 |
| 各 BC | 各端组合查询 | 各端通过应用查询请求所需视图 | 字段受控且标示时点的结果 | 某源缺失不合成虚假成功 |
同一 BC 对某能力可为上游、对另一能力为下游。关系按能力而不是仅给两模块画一条笼统箭头。对外部不可信语言使用防腐适配；内部以公开应用契约和版本化消息沟通。团队供应关系与具体发布治理尚未建立，不因套用 DDD 模式名称就视为已经落实。
2. 统一授权与允许动作的接缝
- 入口验证凭证、受众与来源真实性，建立主体上下文。
- Identity 提供身份、权限、范围、策略及撤销版本。
- 业务 Owner 提供对象归属、状态、金额等可信业务条件；统一授权机制与业务规则共同形成允许动作及原因。
- 查询返回可见数据和动作提示，敏感拒绝信息按政策裁剪；不让无权查询的用户通过错误信息枚举对象。
- 执行时重新检查权限和业务条件，并用资源版本、业务幂等和本地事务避免先检查后变化造成错误写入。
- 异步步骤记录原发起者、执行服务主体和因果关系；重新评估权限时仍需保证已承担义务的恢复动作有独立、受限的系统执行依据，不能因用户登出就遗弃退款或清理流程。
有效能力用于减少无效请求，不是长期通行证。缓存键、时效及失效机制要覆盖主体、范围、策略与资源版本；具体性能目标、最大撤权窗口与失效降级在授权契约中明确。
3. 关键流程由谁协调
以下沿用现有业务流程语义作为输入；不是新建通用 Saga 或替换机器 Registry。
| 流程 | 建议业务协调 Owner | 各步骤 Owner | 完成的含义 | 失败与恢复责任 |
|---|---|---|---|---|
| 顾客结算与订单确认 | Commerce | Commerce 报价/订单/资金；Demand 承诺 | 全部必要门禁满足并确认标准订单 | Commerce 保存步骤进度；Demand 本地确认/释放；资金未知查原操作 |
| 取消及退款 | Commerce | Fulfillment 判断停止；Demand 释放；Commerce 资金处理 | 政策所要求的商业与副作用结果已收敛 | 区分请求受理、商业取消、退款与停止结果；不全链改一个 status |
| 订阅周期出单（非周计划默认机制） | Demand | Demand 锁周期与权益；Commerce 标准订单 | 周期来源关联唯一初始出单结果及后续订单谱系 | 原意图重试查原结果；明确新购/替换使用新意图和新单 |
| 一周购买与逐日确认 | Commerce 协调购买；Demand 裁决每日授权 | Customer 餐次；Commerce 资金；Demand 确认/到期；Fulfillment 门禁 | 已付不自动放行，只有本次合法确认才有执行依据 | Demand 补扫到期；Commerce 自动关单和核算，不依赖用户登录 |
| 已成交换菜 | Commerce | Fulfillment 冻结/永久停止；Demand 撤销旧授权；Commerce 旧单终态、新单及资金 | 前驱不可执行，后继接受完成；每日授权独立 | 新单失败不能复活旧单；补偿核验原资金目标 |
| 购买批次自动结算 | Commerce | Commerce 分配/应收/退款；Finance 核算解释 | 必要资金结果收敛；未决部分有明确责任 | 未确认停送不等于已退款，晚到事实用关联调整 |
| 履约与包裹形成 | Fulfillment | Supply 接受物料变更；Fulfillment 作业包裹 | 已配置的质量、物料及包裹门禁完成 | 每步独立回执；未完成绑定不能假装追溯完整 |
| 售后方案执行 | Commerce | Commerce 退款/补发订单；Supply 处置；Fulfillment 回收；Demand 适用承诺调整 | 方案规定的所有必要动作及证据达到关闭条件 | 下游部分失败保留未决；Case 关闭不伪造资金或物理完成 |
| 质量召回 | Supply | Supply 影响与隔离；Fulfillment 停止/回收；Commerce 售后 | 影响对象的处置证据可核对 | 传播失败可见，危险动作在 Owner 处检查有效质量条件 |
| 外部订单导入与回传 | Channel | 各内部 Owner 接受业务意图 | 外部来源与内部结果明确关联 | Channel 重试/对账外部动作；不能重做内部已完成资金动作 |
| 财务过账 | Finance | Finance 接收、规则与期间、分录 | 来源被正确解释或明确挂起 | 源事实有误回原 Owner，分录有误走冲销/修正 |
| 客户合并与隐私处理 | Customer（账号变更由 Identity 负责） | 各 Owner 处理自身引用与依法需保留的事实 | 处理范围、结果和未决项可审计 | 分步推进不删除历史；具体保留政策待定 |
| 分析重算 | Analytics | 源 Owner 修源、Analytics 重建 | 新口径/数据通过验证后发布 | 旧版本保持可读并显示新鲜度，不篡改交易数据 |
4. 一致性和恢复约束
- 本地强约束：容量争抢、资金可退余额、物料分配与有效质量、任务归属、分录平衡/期间门禁等，必须由事实 Owner 原子检查和写入。具体聚合边界在下一层定义，不能认为一个 BC 就是一个大事务。
- 跨域一致性：使用显式协调、幂等命令和可靠事件；不承诺一个数据库部署便使全部业务原子化。
- 事件重放需验证业务身份及契约版本；去重仅看 eventId 不足以消除不同事件表达同一经济动作的重复效果。
- 查询投影最终一致；权威动作重新判断。传播时限和源不可用时能否继续，按具体风险在契约中明确。
- 分布式异常保留已发生事实。支付、交付、召回无法像数据库写入一样统一撤销；采用补偿、更正、前向恢复和对账。
- 技术 Job 成功只证明一次执行返回；业务流程完成必须由协调 Owner 核对所有必要事实与回执。
5. 后台岗位动线引出的公共接缝（2026-09-19）
本节为本轮架构工作稿增量。产品使用方式见 后台完整设计（历史材料保留在 docs_bak/），跨端语义以本目录为主讲，不冻结 HTTP 路径、字段名或机器枚举。
5.1 动作预告与执行同源
所有入口通过同一应用能力获取对象可见视图与有效动作。动作说明至少表达：业务动作身份、是否可执行、安全原因、允许输入约束、是否需复核/确认、影响摘要，以及判断依赖的主体授权、策略和资源版本。契约应明确查询时点与失效处理；字段级拒绝不泄露隐藏对象。
动作预告不保留资源、不承诺执行成功；最终执行重新鉴权并检查业务不变量。预览依赖变化时要求刷新并重新确认影响，不能只检查页面版本。批量每项独立检查；异步恢复区分新人工意图和履行既有义务的受限执行依据。
5.2 正常待办、责任分派与业务事实
业务 Owner 定义“何时需要某动作、何时该待办已不再需要”，输出可授权的最小索引与来源身份。Platform 可以维护跨域工作索引、认领、分派、交接和通知，但不能拥有第二套订单、售后或质量状态。正常待办不是 ExceptionCase 的强制子类型。
交接的发起与接收不同；接收前责任不默默消失。撤权后由有权主管/团队接管，不能因原人失去权限使工作无人负责。交接版本防并发，接收资格与业务执行权限分别校验。索引落后时回源，源业务完成不因工作索引未刷新而重复执行。
监控事件、通知、Incident工单和自动化流程由通用监控与自动处置平台维护独立生命周期。平台协调的是响应，不接管本节§3各业务流程。鼎味自动建单和恢复模板通过场景包绑定；状态规则、恢复证据和动作权限由对应源Owner提供。静默/抑制只改变显式响应策略，不表示源问题解决。
5.3 订单变更的协调边界
Customer 修改地址簿只改变客户主数据。已成交订单的改址/改期由 Commerce 接收明确变更意图并保留原成交依据、变更原因、客户确认和新安排关联。Demand 判断承诺变化，Fulfillment 判断实际执行能否调整；不由后台直接修改多个领域。
多步骤变更不宣称跨域原子完成。变更尚未影响原义务时被拒绝，原义务保持有效并明确告知；取得执行冻结后不得静默解冻送旧菜。已成交换菜先取得永久停止证据、终止旧单，再关联新单和合法资金分配；旧单一旦终态永不恢复。新单失败使用核验、补偿或明确新购，不覆盖原成交。改址/改时是否可追加受控修正由具体契约决定，不等同任意改单。协议见交易级严谨性，确认窗口与未切配可申请取消/换菜已明确，见确认政策；具体收费、部分处置和改址改时细则仍待定。
5.4 定价与物料事实的入口一致性
Commerce 拥有价格决定及生效版本；Catalog 提供商品/规格与发布事实，不能因价格页面在“商品经营”下就取得定价写入权。生效变更、历史报价及成交快照分别处理；范围/区间重叠与保价政策待正式规则确定。
Supply 拥有物料账、有效质量条件和更正决定。现场观察可以来自作业端或授权后台录入，但必须标记来源，经 Supply 接受才成为物料事实。审批不是余额修改；执行时重新检查当前账本与质量条件，错误更正追加补正，保留原历史。
5.5 查询、回执与恢复
服务中心可提供岗位组合视图，保持源状态、版本和新鲜度；部分源缺失不合成虚假业务结果。操作受理、协调进度、源业务事实、工作责任和通知回执分别表达。
响应丢失后查询原业务请求，业务唯一性不只靠传输去重。协调 Owner 负责部分成功后的补偿/前向恢复及终点核对；浏览器不串联多个 Owner 写操作承担事务。角色撤销后回执读取也需授权，在途义务由受限恢复主体继续，审计保留原发起者和实际执行者。