# 鼎味系统架构：业务事实、交易边界与服务闭环

> 2026-09-29 · 架构整编审阅稿。范围：清洗和审查既有架构，不做原型映射，不修改页面。
> 本文是顺序阅读入口，不复制精确状态表。既有设计的未决责任不因整编消失；[定案条件](DECISIONS.md)未关闭前，不宣称已冻结为可实施最终版。

## 1. 系统要承担的责任

鼎味为顾客提供可提前安排、逐日自主确认、按约配送、全链路可追溯的生鲜服务。用户可以先决定一周吃什么并集中付款；付款核验成功且订单成立后即可提前确认各次配送，无需每天重复确认。配送当日北京时间16:00（后台可配置）仍未确认时间的订单自动取消；提前确认的订单按约配送，临时不需要须主动申请取消。精确机制见[确认政策](05-domain/CONFIRMATION-POLICY.md)。

系统的严谨性体现在：不猜测用户同意，不重复收钱或做货，不复活终态订单，不以“人工处理”掩盖没有出口的流程。正常业务自动推进，异常保留真实事实并有可追踪的恢复责任。详细业务输入见[一周无忧](05-domain/WEEKLY-CARE-PLAN.md)。

## 2. 文档如何构成一份设计

| 需要回答的问题 | 唯一主讲 |
| --- | --- |
| 为什么做、已明确的顾客权利是什么 | [业务意图](05-domain/WEEKLY-CARE-PLAN.md) |
| 确认何时开放、何时自动取消、配置如何生效 | [确认政策](05-domain/CONFIRMATION-POLICY.md) |
| 哪个领域负责什么、谁能修改事实 | [事实归属](07-bounded-context/OWNERSHIP.md)、[上下文协作](07-bounded-context/CONTEXT-MAP.md) |
| 对象身份、金额、执行数量和并发如何保护 | [交易不变量与协议](08-domain-model/TRANSACTION-INTEGRITY.md)、[一致性边界](08-domain-model/CONSISTENCY.md) |
| 从哪个入口进入、成功或失败后到哪里 | [业务流程与出口](05-domain/WEEKLY-CARE-FLOW.md) |
| 通用监控如何检测、告警、通知与安全自愈 | [监控与自动处置平台](platform/MONITORING-AUTOMATION.md)；业务扩展单列[鼎味场景包](platform/DINGWEI-SCENARIO-PACK.md) |
| 某状态究竟允许哪些迁移 | [状态定义及检查边界](state/FRESH-DELIVERY.md)；精确迁移只在其引用的 JSON 中维护 |
| 什么尚未定案、为什么不能隐藏为默认值 | [定案条件](DECISIONS.md) |
| 本次究竟核查了什么 | [清洗审查记录](../reports/review/ARCH-2026-09-29-consolidation.md) |

正文引用负责细节的文件，不以“后写的段落”隐式覆盖另一份有效规则。发现冲突须修正两端或明确保留未决。历史 REVIEW 是当时的证据，不是另一套现行规则；模板和未展开的子域卡不作为已经完成的设计输入。

## 3. 十个责任域，而不是十套订单系统

| 责任域 | 核心事实 | 对主链的支撑和边界 |
| --- | --- | --- |
| Identity | 身份、角色、范围、授权策略 | 每次动作校验对象和金额权限；管理员也不能绕开终态；恢复服务身份不得扩大原义务 |
| Customer | 客户、地址簿、家庭菜谱、餐次意图 | 保持生活安排连续；改菜谱或地址簿不修改成交快照 |
| Catalog | SKU、切配规格、推荐菜谱、发布版本 | 提供可追溯规格；发布不等于库存可用或价格承诺 |
| Supply | 来源、批次、物料账、质量与追溯 | 供给与隔离决定由自身裁决；退货、取消不自动恢复可售库存 |
| Demand | 服务承诺、每日安排、确认与截止 | 裁决本次是否接受配送；容量管理是内部承接能力，不是让顾客抢资格 |
| Commerce | 报价、订单、购买批次、支付、退款、售后 | 协调商业义务与资金来源；不直接写配送授权或现场结果 |
| Fulfillment | 执行门禁、作业、包裹、交付事实 | 只有授权、资金、质量和唯一数量权均满足才开工；现场未知不重复做货 |
| Finance | 经济来源、分录、期间、核算 | 解释已验证经济事实；财务更正不改订单终态，也不凭过账触发再退款 |
| Channel | 外部销售渠道适配、来源绑定、回传 | 外部观察须经业务 Owner 接受；支付渠道适配仍属 Commerce |
| Analytics | 口径、指标与投影 | 消费源事实、可重算；不能由报表差异直接改钱或发货 |

Platform 提供调度、传输、审计设施、工作索引及[通用监控与自动处置](platform/MONITORING-AUTOMATION.md)，拥有其技术配置、事件和执行生命周期，不成为第十一个零售业务事实 Owner。监控内核不依赖鼎味业务，业务通过场景包接入；Analytics保留分析口径，平台不重复定义。小程序、后台、作业端调用相同应用能力；入口不同不产生独立交易规则。领域边界不等于微服务部署边界，本轮不凭十个上下文推导十个服务或数据库。

## 4. “计划”在底层的表示

计划按周组织阅读，按稳定餐次表达意图；交易按购买批次和独立商业义务记录；配送按明确的行与数量范围接受授权。周、日期和餐次均不是订单的天然唯一键。

```mermaid
flowchart LR
    M[Customer 餐次及修订] -->|购买来源引用| O[Commerce 订单及不可变明细]
    B[Commerce 有限购买批次] -->|明确纳入范围| O
    P[Commerce 原实收及分配] -->|合法资金依据| O
    O -->|行与数量范围| D[Demand 每日安排及确认记录]
    D -->|本次明确授权| G[Fulfillment 执行门禁与数量份额]
    O -->|商业条件| G
    Q[Supply 质量与物料事实] --> G
    G -->|实际结果| S[Commerce 结算退款及售后]
    S -->|经济事实| F[Finance 核算]
```

对象边界及身份规则以[交易协议 §2](08-domain-model/TRANSACTION-INTEGRITY.md#2-对象基数与唯一性)为准。必须同时有：

- 持久业务来源唯一性：同一购买意图按被接受的拆分范围只产生一次订单效果，换幂等键不能重复下单。
- 请求幂等：同主体、动作、目标、请求摘要的重复请求返回原结果，同键不同内容拒绝。
- 当前版本裁决：新请求即使拥有不同身份，也不能覆盖已改变的对象。
- 谱系额度：原单和替换单的资金、数量不能各自检查通过后双重使用。

**同一餐次允许关联历史取消单和新的有效订单，但终态旧单不能再履行。** 已确定订单不跨配送日期和地址；独立时段需要独立商业范围，同日多次购买仍可多单。合并配送不合并订单或继承授权，详见确认政策；部分商品取消/售后细则仍归D-02/03。

### 术语收敛

| 规范称呼 | 所指对象 | 容易混淆的旧称 |
| --- | --- | --- |
| 收款目标 PaymentIntent | 一次稳定业务收款目的 | PaymentGoal 只是同义描述，不另建一套目标 |
| 支付尝试 PaymentAttempt | 该目标下的一次合法外部尝试 | 重试次数不是收款目标数量 |
| 实收事实 PaymentTransaction | 经验证的原渠道交易 | Receipt 在资金段落指此事实，不是消息 ACK |
| 替换请求 ReplacementRequest | 前驱停止、关联新单与资金协调 | 不与泛称 Substitution 再维护两套换菜状态 |
| 结算执行 SettlementRun / 结果 SettlementRecord | 受范围版本约束的核算执行及已验证结果 | ReconciliationRun 是对账执行，不是再次结算或退款授权 |
| 关联调整 Adjustment | 结清后新事实的独立更正 | 不重开旧批次、旧订单或改原实收 |

每日安排统一由 DeliveryInstruction 承担鲜配确认事实；旧模型中的 Reservation 是通用预约概念，不授权另存一套鲜配确认状态。其在其他服务模式中的适用性须另行定案。

## 5. 主业务链的门禁与终点

业务流程详见[完整流程](05-domain/WEEKLY-CARE-FLOW.md)，这里定义跨域闭环的判断标准，而不复制迁移表。

1. **计划到购买**：草稿不产生商业义务；Commerce 接受范围、报价和稳定来源。付款请求受理不等于到账，到账不等于订单已接受。
2. **付款到每日确认**：资金已核验、订单合法成立后仍等待本次确认。晚到款不能复活已关闭订单；无法承接的实收进入原目标核验和有依据的退回流程。
3. **确认或自动到期**：Demand 对同一安排和版本裁决；付款后可提前确认，默认配送日16:00只终止pending，Commerce自动取消对应订单；accepted不再重复确认。付款、选时间、通知已读都不能替代明确同意。确认费支付成功但安排已到期，须处理这笔费用，不能强行接受安排。
4. **授权到执行**：Fulfillment 校验当前授权、资金、质量、数量份额及适用的前驱停止证据。可以提前预测采购，不能把预测当订单级不可逆切配许可。
5. **更换或取消**：未改变原义务的请求被拒绝，原义务仍有效；正式冻结后不得静默恢复旧菜。未切配可申请取消/换菜，停止与开工竞争；已成交换菜采用永久停止旧执行、旧单终态、关联新单及受控差额，不覆盖原成交。
6. **实际交付到结算**：交付、部分交付和异常处置使用真实证据。订单结束、退款结束、批次结清是不同终点。结清后售后及更正使用关联对象，不逆转历史终态。

“流程完成”至少核对商业处置、授权结束、执行范围、资金结果和必要会计来源交接；这不要求把所有领域压入同一个事务。Finance 的过账未完成不伪造完成，也不当然阻止已合法授权的顾客退款；是否存在特定合规前置要求须另行确定。

## 6. 并发、钱与货的底线

确认与到期必须争用同一 Demand 权威记录；冻结与开工必须争用同一 Fulfillment 门禁；重分配与退款必须保护同一原款额度。只给每个请求加版本号不能解决这些跨对象竞争。

每笔实收的互斥分配、UNKNOWN 占用及更正方式见[资金协议](08-domain-model/TRANSACTION-INTEGRITY.md#6-资金守恒与自动结算)。付款或退款超时先查原目标，不释放未知额度另做一次。零应付有合法报价依据，不伪造外部零元流水。

实际切配、封装、交付不可用数据库回滚抹除。旧设备、旧任务、迟到事件必须受相同执行范围和 fence 约束。设备不能核验执行权时，不允许离线自主进行不可逆动作；发生过但回执丢失时隔离核实，不重派同份作业。

本地事务提交状态、版本、审计、必要额度与 Outbox；接收方 Inbox 去重和业务效果共同提交。网络传输可以重复，业务效果不能重复；不以 exactly-once 宣传替代守卫。完整约束见[一致性边界](08-domain-model/CONSISTENCY.md)。

## 7. 自动化与运营后台的业务支撑

本节定义系统能力，不对应页面、按钮或路由。

平台先定义通用对象、检测/响应模型和扩展契约，再由[鼎味场景包](platform/DINGWEI-SCENARIO-PACK.md)绑定业务语义。普通使用者通过类型化配置和场景引导创建策略，不编写PromQL；Prometheus为候选底层引擎，不是规范策略的事实源。正常到期、关单和核算仍在原业务Owner执行，监控负责检测失常并调用获准的恢复能力。平台精确合同与运行验证的缺口见D-15。

| 必须具备的能力 | 自动责任 | 运营介入及关闭依据 |
| --- | --- | --- |
| 到期判定与停送 | Demand 持久截止补扫；Commerce 协调关单 | 只接异常；不能因补扫失败默认继续配送 |
| 确认提醒 | 受限通知任务、可追踪回执 | 通知失败不构成确认；客服解释和催办不代替授权 |
| 替换与取消协调 | Commerce 恢复持久步骤并查询停止回执 | 只有原状态未改才可明确拒绝；部分完成继续核验，不一键复原 |
| 批次核算与退差 | Commerce 按确定范围和政策自动执行 | UNKNOWN、差异、争议进入受限核验；正常业务不需人工逐笔退款 |
| 供给预测与实际采购 | 计划预测与已确认需求分别标识 | 不把已预测当已售，不把计划取消当物料自动回库 |
| 质量、部分交付与售后 | 源 Owner 提供影响范围和独立回执 | 召回、补发、退费各自执行并验证；案件关闭不等于所有动作成功 |
| 工作责任与审计 | 平台索引等待年龄、来源与责任 | 交接被接受才转移责任；工单已分派不是业务已解决 |
| 通用监控与自动处置 | 接入观察、版本化策略转译、检测、事件、路由和受控套餐 | 来源未知不判恢复；源结果、告警、工单与自动执行分别核验；详见平台主讲 |
| 源事实组合查询 | 各 Owner 输出受控视图和来源版本 | 不可用显示待核验，不从缺失推断未付或已取消 |

顾客代办必须有可验证授权，员工身份不能天然代替顾客同意。未确定代办证据契约前，不开放代确认能力；已承担的退款等义务则由受限服务身份继续，不因员工离职或用户登出遗弃。

工作项只有在源业务必要结果已核实，或关联了经授权的继续处置对象并明确尚未解决范围时，才可结束其本次处理；不能把“移交成功”展示为“退款成功”。真实岗位、时限和升级链尚缺，见 D-06/07。

## 8. 定价、政策和故障恢复

政策应具有身份、版本、适用范围、生效时间、约束和使用快照。新版本不能追溯改变已经接受的价格、截止和授权；报价跨版本须重新校验，影响用户责任时重新取得同意。无有效政策时拒绝新增承诺，并保留既有义务的恢复能力。

参数化不能掩盖商业语义未决。未切配可申请取消、按配送日和地址拆单、实际重量计价已确定；部分商品处置、超重处理和实际应收确认时点，不是随便填一个数字即可完成的设计。业务取舍、契约缺口、运行证据分别记录在[定案条件](DECISIONS.md)。

恢复以持久目标、源回执和金额/数量守卫为依据：自动查证在预算内进行，超预算升级但不伪造失败终态；响应丢失查询原操作；相反晚到证据形成差异和调整，不翻转已验证终态。所有未完成义务必须保持可查询、可归责。

## 9. 迁移、回滚与验收

本轮不执行迁移。后续切换须盘点旧订单、授权、资金、执行范围及未决消息，建立明确水位和唯一写入方；未知旧状态隔离，不强行映射为取消或成功。回滚软件保留新发生的资金和物理事实，恢复备份后先与外部来源核对再开放写入。

验收分别验证：来源唯一性、终态不可逆、逐日授权、金额和数量守恒、两类核心状态竞争、部分完成恢复、撤权、跨日时间边界、批次结算并发、晚到事实、迁移及备份恢复。正常路径通过不代表这些反例通过。

六类候选状态机的结构检查可以运行；业务 guard、真实数据库竞争、支付渠道与现场防重尚未验证，其他对象的精确状态合同也未齐备。当前整编解决阅读主线、术语冲突和流程出口表达，**不以文档整理冒充全部架构已定案或产品已验收**。