ddd-subdomains

name	ddd-subdomains
description	识别业务能力并分类子域（Core/Supporting/Generic），产出核心域声明与所有权建议。
risk	safe
source	self
tags	[ddd, strategic, subdomains]
date_added	2026-05-08

DDD Subdomains

🌐 English version: English

使用时机

• 已完成领域发现（事件流与命令/事件候选已就绪），需要将领域切分为子域。
• 需要明确"什么是核心竞争力、什么可以外购/复用"的战略决策。
• ddd-context-map 报告"上帝上下文"或子域误分时，作为回溯目标重新执行。

输入要求

• 必需：事件流、命令/事件候选、边界线索（来自 ddd-discover）。
• 可选：当前系统能力清单或模块清单、业务差异化假设、竞争优势描述（来自 ddd-scope）。

流程

1. 提取能力集：从事件流中抽取业务能力（Capability），去重合并同义能力。
2. 属性标注：为每个能力标注业务价值、复杂度、变更频率、外部依赖程度。
3. 分类：按 DDD 子域类型分类——Core（核心差异化）、Supporting（必要但非差异化）、Generic（通用可复用）。
4. 核心域声明：形成核心域声明文档——为什么它是核心、衡量指标、长期演进方向。
5. 所有权建议：建议团队归属，对齐语言边界与一致性边界；标注跨团队协作点。
6. 输出边界候选：为 ddd-contexts 提供子域到上下文的初步映射建议。

输出

工件	结构要求
能力清单	表格：能力、说明、关联事件、上下游依赖
子域分类表	表格：能力/能力组、子域类型（Core/Supporting/Generic）、分类理由、建议投入
核心域声明	1 页以内：价值、边界、衡量指标、风险、演进方向
所有权建议	表格：能力/子域、建议团队、依赖方、协作方式
边界候选	列表：子域到上下文的初步映射建议

校验清单

• 每个能力有分类理由，业务方与技术方均可接受
• 核心域声明包含可衡量的业务指标
• 至少识别 3 个跨团队协作点并给出协作建议
• Core 子域数量 ≤ 总子域的 1/3（核心域不应过多）
• 边界候选可被 ddd-contexts 直接消费

回溯触发

• 无法区分 Core 与 Supporting（所有能力看起来同等重要） → 回溯至 ddd-scope，业务价值主张需重新澄清。
• 被 ddd-context-map 触发回溯：循环依赖或"上帝上下文"暗示子域划分有误。

示例

@ddd-subdomains
基于以下事件流和边界线索，帮我识别子域并分类：
[粘贴 ddd-discover 的事件流表与边界线索]
请输出能力清单、子域分类表、核心域声明与所有权建议。