# 鼎味业务域

> 状态：working-draft（第一项梳理，尚未完成业务范围核对）\
> 上游：[顶层治理指南](../../../AGENTS.md)\
> 下游：[候选子域目录](../06-subdomain/README.md)\
> 业务 / 设计维护责任人：待指定\
> 日期：2026-09-18

## 1. 我们需要有什么

已知项目目标是建设纯线上、预约配送、全链路可追溯的生鲜零售与履约系统。所有参与方使用同一套权威业务事实，不因小程序、后台、作业端或渠道不同而分裂系统。

基于现有规划，先提出以下能力盘点，作为本次重整的工作稿，不直接确定子域边界或首发范围：

| 业务需要 | 期望得到的结果 | 下一步要明确 |
|:---|:---|:---|
| 经营商品与内容 | 顾客理解可以买什么，经营者能够维护和发布 | 商品、内容、销售政策的边界 |
| 建立客户及参与关系 | 系统能够持续服务顾客并支持团长等参与方式 | 团长、客户服务与增长的业务范围 |
| 承接预约及持续需求 | 系统知道可接受的需求和应兑现的服务承诺 | 预约、订阅与实际供给如何协作 |
| 完成交易及交易后处理 | 各端共同创建、查询、处理同一订单及相关资金事项 | 修改、取消、支付、退款的明确业务动作 |
| 管理供给与质量证据 | 合格物料及其来源、变化和去向可解释 | 质量、库存、追溯的责任边界 |
| 兑现交付 | 承诺成为真实作业及可证明的交付结果 | 作业与供给、订单的协作关系 |
| 核算经营结果 | 经济事实成为可核对的账务结果 | 交易、结算、会计核算如何分界 |
| 协作外部渠道 | 外部参与方使用共同业务能力并获得一致结果 | 支持的业务场景及适配责任 |
| 理解经营情况 | 可追溯数据支持分析与决策 | 指标、建议、执行的责任边界 |
| 管理组织与授权 | 各参与方明确知道能够执行哪些操作 | 身份、角色、范围与业务条件 |

## 2. 它是什么

工作定义：鼎味业务域承接线上生鲜零售从经营准备、需求承接、交易到履约、售后与核算的协作过程，以统一业务服务中心保护各领域的权威事实。

小程序、后台和作业端是操作入口；API 是调用契约；子域描述业务问题；限界上下文描述模型适用边界。当前先识别业务问题，不用页面导航、已有代码包或数据库 Schema 代替业务划分。

范围依据及待核对事项：

- 纯线上、预约配送、可追溯和统一系统是已有项目方向。
- 现有材料出现“生鲜”与更具体的“猪肉”口径：经营品类边界待明确，不在本页自行扩张或收窄。
- 服务区域、配送方式、运营策略及外部渠道的具体范围需有业务依据；本文不设默认值。
- 整体目标、长期能力与首发交付范围分别登记，不能互相代替。

## 3. 谁参与，谁调用

| 参与方（来自现有规划，待逐项核对） | 入口或调用方式 | 使用目的 |
|:---|:---|:---|
| 顾客 | 小程序 | 了解商品、购买、预约、查询和发起售后 |
| 团长 | 小程序中的角色工作区 | 在授权业务关系下参与活动、服务或交接；具体能力待梳理 |
| 运营、客服 | 后台 | 经营配置、客户服务及受控异常处理 |
| 供给、质量人员 | 后台 / 作业入口，分工待明确 | 维护供给与质量依据 |
| 加工、仓储、配送人员 | 作业端 | 执行并提交实体作业证据 |
| 财务人员 | 后台 | 核对经济事实与处理账务 |
| 组织管理员 | 后台 | 维护成员职责及授权范围 |
| 外部系统 | 集成 API / 回调 | 发起授权请求并接收业务结果 |
| 内部领域与异步进程 | 应用契约 / 事件 | 推进跨领域业务及可靠恢复 |

该表是参与者盘点，不是已生效的角色权限表。一个人可以有多个业务角色，同一角色也可能通过多个入口操作。

## 4. 他们如何共同使用系统

先用“顾客创建订单 → 后台查询同一订单 → 授权人员执行允许的动作 → 顾客看到变化”作为贯穿样例。完整展开顺序为：

1. 说明参与者希望得到的业务结果。
2. 说明各自输入的意图、前置条件与可操作对象。
3. 指出事实由谁判断和修改，其他领域如何协作。
4. 说明权限和允许动作如何事先获知，执行时如何最终校验。
5. 说明结果如何返回并被其他参与方看到。
6. 检查拒绝、重复、并发、超时、部分失败和恢复。

后续还需补齐商品经营、预约、供给、履约、售后、核算及其他目标场景。单一订单样例不证明整体业务已覆盖。

## 5. 如何进入子域设计

2026-09-29 补充的核心使用链为：[闲时规划 → 一次购买 → 可提前确认各日 → 受控履约 → 核算及政策内资金处理](WEEKLY-CARE-FLOW.md)。周计划是 Customer 意图；购买批次和订单是 Commerce 商业事实；Demand 保存本次配送授权；Fulfillment 保护唯一执行权。已取消/到期/完成订单不复活，未切配可申请取消/换菜，采用关联新单方案；按实际重量计价。付款后可提前确认，默认配送日16:00未确认自动取消，已确认无需重复；详见[确认政策](CONFIRMATION-POLICY.md)。正常流程无需人工每天取消或结算；后台处理真实异常，不能绕过与小程序相同的门禁。自动退款时点及分摊等仍待政策确认，见[交易严谨性](../08-domain-model/TRANSACTION-INTEGRITY.md)。这条主链补充不消除其他业务范围未决项。

能力盘点形成初步共识后，逐项进入 [候选子域目录](../06-subdomain/README.md)，沿“需要什么 → 是什么 → 谁参与 → 如何使用 → 设计收敛”补齐。子域边界、分类、事实 Owner、BC 及公共契约由这些场景推导；不直接复制旧模块结论。

## 6. 未决项与下一步

| 待决项 | 影响 | 下一步 / 责任 |
|:---|:---|:---|
| 能力清单是否遗漏或包含不需要的业务 | 整体域范围 | 主会话继续核对业务输入；业务决策与维护责任人待明确 |
| 经营品类与长期 / 首发范围 | 子域模型适用范围 | 核对业务目标，不自行假定 |
| 候选子域拆合及业务角色完整性 | 后续边界与授权 | 按候选目录逐项梳理并记录反例 |
| 旧 DDD 和现有模块定义尚未完成迁移 | 新旧设计可能冲突 | 采用本目录 README 的过渡规则，保留出处并逐项裁决 |

本页完成条件：整体需要、业务定义、参与方、主要使用链和范围问题均得到明确记录；之后继续逐个子域，不跳到 API 字段、表结构或开发排期。