# 05｜业务域：自顶向下设计入口

> 状态：重整中；域为工作稿，子域为候选占位。\
> 治理依据：[AGENTS.md](../../../AGENTS.md)\
> 日期：2026-09-18

## 1. 固定的思考顺序

**我们需要有什么 → 它是什么 → 谁参与和调用 → 各自如何使用 → 收敛具体子域设计。**

先回答业务问题，再推导边界、事实归属、授权与数据/API/事件契约。最后才由业务增量派生 REQ 和 TASK。

## 2. 文档入口

最新业务输入：[一周无忧计划机制](WEEKLY-CARE-PLAN.md)（2026-09-23）。明确提前规划、一次支付、付款后可提前确认各次配送；配送当日16:00未确认自动取消，已确认不重复确认。最新[确认政策](CONFIRMATION-POLICY.md)承接配置、切配取消边界及实际重量计价；退款与计价细则仍待定，不是已冻结合同。

2026-09-29 增量：[不可逆订单与每日流程](WEEKLY-CARE-FLOW.md)，区分生活意图、购买批次、商业订单和每日授权；精确候选迁移与交易不变量从[架构总入口](../README.md)进入。

域与子域是 `architecture/` 下的平级目录：`05-domain/` → `06-subdomain/`。序号表示设计层次与阅读顺序，子域正文直接放在 `06-subdomain/`，不再嵌套一层。后续层级沿用平铺原则，通过链接表达上下游关系。

| 文档 | 用途 | 当前进度 |
|:---|:---|:---|
| [DOMAIN.md](DOMAIN.md) | 整体业务需要、定义、参与者与主要使用链 | 第一轮工作稿；待核对 |
| [SUBDOMAINS.md](../06-subdomain/README.md) | 候选子域、边界问题与逐项梳理顺序 | 十个候选项，不固定最终数量 |
| [SUBDOMAIN-template.md](../06-subdomain/SUBDOMAIN-template.md) | 单个子域的统一梳理结构 | 模板 |
| [06-subdomain/](../06-subdomain/README.md) | 各子域独立占位及后续设计正文 | 全部 placeholder |

当前从 DOMAIN 开始；核对整体需要之后，再逐个展开子域。不会因存在旧模块文档就跳过前四步。

## 3. 与旧材料的过渡关系

本目录是本次域与子域重整的唯一编辑主线。旧 DOMAIN（历史材料保留在 `docs_bak/`）、SUBDOMAIN（历史材料保留在 `docs_bak/`）、BC 目录（历史材料保留在 `docs_bak/`） 和 模块架构（历史材料保留在 `docs_bak/`） 保留为待核对来源。

旧材料已经退出当前架构基线，仅保留历史追溯。其旧 CURRENT 声明不产生当前权威；新工作稿也不因旧稿退出就自动成为已批准契约。冲突须记录双方出处、影响和待决点，经新设计评审形成结论后才能实施。

本轮已展开限界上下文与领域模型的候选分析，未完成全部子域正文或公共契约。外部开发材料仍引用的旧规则、模板和机器契约需要后续逐项收敛。

## 4. 成熟度与责任

placeholder 表示已有讨论位置；working-draft 表示已开始梳理；review-ready 表示已按模板核对完整性、可以评审。成为有效基线还须记录明确结论、版本和维护责任，不能通过改标签代替设计证据。

既有实现与验证情况在本次重整中均未重新评估。设计维护责任尚未指定，保留为待决项。当前不锁定 REQ，不改 Runtime，不进入实现。