06｜候选子域目录

状态：draft inventory；不是已批准的子域或 BC 划分。
上游：业务域
日期：2026-09-18

后续层：07｜限界上下文已依据现有业务输入开始候选分析；本目录仍为占位清单，不因后续分析启动就升级为完整设计。边界拆合及遗漏反馈见 07 审查记录。

1. 先盘点业务需要，再验证边界

下表从既有规划中提取业务问题作为讨论起点，避免遗漏；不以旧 BC 数量规定新的子域数量。允许在梳理中新增、拆分、合并或移除候选项，并记录理由及来源去向。分类和 BC 映射在使用场景明确后再形成。

候选子域	需要具备的业务能力（待核对）	主要边界问题	本次状态
SD-01 商品与内容经营	需要清楚表达卖什么、如何展示以及何时可供顾客选择。	商品定义、内容经营、发布是否属于同一业务边界？	placeholder
SD-02 客户与业务关系	需要识别服务对象，维护联系、服务及参与经营活动的关系。	客户服务、团长关系与增长活动如何分界？	placeholder
SD-03 预约承诺与订阅	需要表达可以接受什么需求、何时履约以及持续服务承诺。	预约容量与订阅合同是否应分别成为子域？	placeholder
SD-04 交易、订单与售后	需要让购买意图形成统一交易，并支持查询、受控调整及交易后处理。	定价、订单、支付、售后是否需拆分子域，如何保持同一交易链？	placeholder
SD-05 供给、质量与追溯	需要提供合格物料，并解释来源、数量变化及去向。	供给、库存、质量与追溯如何划分责任和协作？	placeholder
SD-06 履约与交付	需要将已接受的承诺转化为真实作业和可证明的交付。	加工、包装、配送如何分工，与物料事实如何交接？	placeholder
SD-07 财务核算	需要把经营产生的经济事实转换为可解释、可核对的账务结果。	交易资金事实与会计核算事实的边界是什么？	placeholder
SD-08 外部渠道协作	需要让外部渠道参与业务，同时保持内部事实与规则一致。	哪些是渠道业务能力，哪些只是技术接入与适配？	placeholder
SD-09 经营分析与决策支持	需要依据可追溯事实理解经营结果并支持行动。	指标、数据质量、推荐与决策执行分别由谁负责？	placeholder
SD-10 组织、身份与授权	需要明确谁以何种职责参与业务，以及能操作哪些对象和动作。	组织业务、身份认证、授权治理与技术设施如何分界？	placeholder

2. 横向技术能力另行登记

文件、通知、Outbox/Inbox、作业、幂等、审计设施等已有输入见平台模块（历史材料保留在 docs_bak/）。这些能力进入后续公共技术基线收敛，不直接把现有 Platform 模块当作一个业务子域。业务通知规则、业务审计含义仍需归属对应业务 Owner。

“组织、身份与授权”保留为候选支撑问题，其业务部分与技术部分的边界仍须梳理。

3. 梳理顺序与完整性检查

2026-09-29 本轮不把占位文档视为完整子域设计；交易严谨性横向需求逐域回填如下。详见交易主讲，SD-02/03/04/06 增补核心场景，其余仍需独立场景展开。

子域	本轮明确的责任 / 反例	下游承接
SD-01	规格版本可追溯，商品修改不改旧成交	DM-03
SD-02	周计划与餐次是意图，不是订阅/钱包/订单	DM-02
SD-03	每日确认与到期互斥；付款不授权配送	DM-05
SD-04	终态不可逆、关联新单、原款守恒、批次结算	DM-06
SD-05	物料数量守恒、质量隔离、取消不凭空回库	DM-04
SD-06	冻结/开工同 gate 裁决，旧任务不能重复切配	DM-07
SD-07	经济来源去重、期间门禁、更正分录不改源资金	DM-08
SD-08	外部作用域防重，UNKNOWN 不盲重发	DM-09
SD-09	替换链不重复统计履约，重算不触发交易动作	DM-10
SD-10	无通用终态 override；恢复主体受限且义务不遗弃	DM-01

先完成整体业务域的能力与参与者盘点，再按上表顺序逐项展开；这是讨论顺序，不是开发排期。发现上游业务依赖时回到对应条目补充，不绕开待决问题。

每次检查：顾客发现与购买、持续服务与团长参与、后台经营与客服、供给质量、实体作业交付、资金核算、渠道协作、经营分析、组织授权是否都有承接位置。该清单来自已有输入，仍需在业务域梳理中检查遗漏，不能当作覆盖已完成的证据。

4. 边界变更记录

日期	变化	理由与影响	结论状态
2026-09-18	建立十个候选业务讨论项；平台技术设施另列	从现有模块抽取业务需要，重新验证子域边界；未批准 BC 映射	占位