name: 领域分析 description: 识别子域并建议有界上下文，遵循领域驱动设计（DDD）战略设计原则。适用于分析领域边界、识别业务子域、评估领域内聚性、映射有界上下文，或当用户询问DDD战略设计、领域分析或子域分类时使用。
子域识别与有界上下文分析
这个技能分析代码库，以识别子域（核心、支持、通用）并建议有界上下文，遵循领域驱动设计战略设计原则。
何时使用
在以下情况应用此技能：
- 在任何代码库中分析领域边界
- 识别核心、支持和通用子域
- 从问题空间到解决方案空间映射有界上下文
- 评估领域内聚性和检测耦合问题
- 规划领域驱动重构
- 理解代码中的业务能力
核心原则
子域分类
核心域：竞争优势，最高业务价值，需要最佳开发者
- 指标：复杂业务逻辑，频繁变化，需要领域专家
支持子域：必要但不具差异化，业务特定
- 指标：支持核心域，中等复杂度，业务特定规则
通用子域：常见功能，可以外包
- 指标：理解良好问题，低差异化，标准功能
有界上下文
一个明确的语言边界，其中领域术语具有特定、无歧义的含义。
- 主要性质：语言边界，非技术
- 关键规则：在边界内，所有通用语言术语无歧义
- 目标：将1个子域对齐到1个有界上下文（理想）
分析过程
阶段1：提取概念
扫描代码库以获取业务概念（非基础设施）：
-
实体（具有身份的领域模型）
- 模式：
@Entity,class, 领域模型 - 焦点：业务概念，非技术类
- 模式：
-
服务（业务操作）
- 模式：
*Service,*Manager,*Handler - 焦点：业务逻辑，非技术工具
- 模式：
-
用例（业务工作流）
- 模式：
*UseCase,*Command,*Handler - 焦点：业务流程，非CRUD
- 模式：
-
控制器/解析器（入口点）
- 模式：
*Controller,*Resolver, API端点 - 焦点：业务能力，非技术路由
- 模式：
阶段2：按通用语言分组
对于每个概念，确定：
主要语言上下文
- 属于什么业务词汇？
- 示例：
Subscription,Invoice,Payment→ 账单语言Movie,Video,Episode→ 内容语言User,Authentication→ 身份语言
语言边界
- 术语含义在哪里改变？
- 相同术语，不同含义 = 不同有界上下文
- 示例："Customer"在销售vs"Customer"在支持
概念关系
- 哪些概念自然属于一起？
- 哪些共享业务词汇？
- 哪些相互引用？
阶段3：识别子域
一个子域具有：
- 独特的业务能力
- 独立的业务价值
- 唯一词汇
- 多个相关实体协同工作
- 内聚的业务操作集
常见领域模式：
- 账单/订阅：支付、发票、计划
- 内容/目录：媒体、产品、库存
- 身份/访问：用户、认证、授权
- 分析：指标、仪表板、洞察
- 通知：消息、警报、通信
分类每个子域：
使用此决策树：
Is it a competitive advantage?
YES → Core Domain
NO → Does it require business-specific knowledge?
YES → Supporting Subdomain
NO → Generic Subdomain
阶段4：评估内聚性
高内聚性指标 ✅
- 概念共享通用语言
- 概念频繁一起使用
- 直接业务关系
- 变化影响组内其他概念
- 解决相同业务问题
低内聚性指标 ❌
- 不同业务词汇混合
- 概念很少一起使用
- 无直接业务关系
- 变化不影响其他概念
- 解决不同业务问题
内聚性分数公式：
分数 = (
语言内聚性 (0-3) + // 共享词汇
使用内聚性 (0-3) + // 一起使用
数据内聚性 (0-2) + // 实体关系
变化内聚性 (0-2) // 一起变化
) / 10
8-10: 高内聚性 ✅
5-7: 中等内聚性 ⚠️
0-4: 低内聚性 ❌
阶段5：检测低内聚性问题
规则1：语言不匹配
- 问题：不同业务词汇混合
- 示例：
User（身份）+Subscription（账单）在同一服务中 - 行动：建议分离到不同有界上下文
规则2：跨域依赖
- 问题：领域间紧密耦合
- 示例：服务A直接实例化领域B的实体
- 行动：建议基于接口的集成
规则3：混合职责
- 问题：单个类处理多个业务关注点
- 示例：服务处理账单和内容
- 行动：建议按子域拆分
规则4：核心中的通用
- 问题：核心业务逻辑中的通用功能
- 示例：账单服务中的邮件发送
- 行动：提取到通用子域
规则5：边界不清晰
- 问题：无法确定概念属于哪个域
- 示例：与多个域有关联的实体
- 行动：澄清边界，可能拆分概念
阶段6：映射有界上下文
对于每个识别的子域，建议有界上下文：
有界上下文特征：
- 名称反映通用语言
- 包含完整领域模型
- 有明确集成点
- 清晰语言边界
集成模式：
- 共享内核：上下文间共享模型（谨慎使用）
- 客户/供应商：下游依赖上游
- 顺从者：下游顺从上游
- 防腐层：上下文间翻译层
- 开放主机服务：发布的集成接口
- 发布语言：良好文档的集成协议
输出格式
领域地图
对于每个域/子域：
## Domain: {Name}
**Type**: Core Domain | Supporting Subdomain | Generic Subdomain
**Ubiquitous Language**: {key business terms}
**Business Capability**: {what business problem it solves}
**Key Concepts**:
- {Concept} (Entity|Service|UseCase) - {brief description}
**Subdomains** (if applicable):
1. {Subdomain} (Core|Supporting|Generic)
- Concepts: {list}
- Cohesion: {score}/10
- Dependencies: → {other domains}
**Suggested Bounded Context**: {Name}Context
- Linguistic boundary: {where terms have specific meaning}
- Integration: {how it should integrate with other contexts}
**Dependencies**:
- → {OtherDomain} via {interface/API}
- ← {OtherDomain} via {interface/API}
**Cohesion Score**: {score}/10
内聚性矩阵
## Cross-Domain Cohesion
| Domain A | Domain B | Cohesion | Issue | Recommendation |
| -------- | -------- | -------- | ------------------ | ----------------------- |
| Billing | Identity | 2/10 | ❌ Direct coupling | Use interface |
| Content | Billing | 6/10 | ⚠️ Usage tracking | Event-based integration |
低内聚性报告
## Issues Detected
### Priority: High
**Issue**: {description}
- **Location**: {file/class/method}
- **Problem**: {what's wrong}
- **Concepts**: {involved concepts}
- **Cohesion**: {score}/10
- **Recommendation**: {suggested fix}
### Priority: Medium
{similar format}
有界上下文地图
## Suggested Bounded Contexts
### {ContextName}Context
**Contains Subdomains**:
- {Subdomain1} (Core)
- {Subdomain2} (Supporting)
**Ubiquitous Language**:
- Term: Definition in this context
**Integration Requirements**:
- Consumes from: {OtherContext} via {pattern}
- Publishes to: {OtherContext} via {pattern}
**Implementation Notes**:
- Separate persistence
- Independent deployment
- Explicit API boundaries
最佳实践
要做的事情 ✅
- 专注于业务语言，而非代码结构
- 让通用语言指导边界
- 客观测量内聚性
- 识别清晰集成点
- 分类每个子域（核心/支持/通用）
- 首先寻找语言边界
不要做的事情 ❌
- 不要按技术层分组
- 不要强制单全局模型
- 不要忽略语言差异
- 不要直接耦合领域
- 不要按架构创建上下文
- 不要消除所有依赖（有些是必要的）
分析检查清单
对于每个概念：
- [ ] 属于什么业务语言？
- [ ] 属于什么域/子域？
- [ ] 是核心、支持还是通用？
- [ ] 与其他概念有何关系？
- [ ] 依赖是否在同一域内？
- [ ] 任何语言不匹配？
对于每个域：
- [ ] 通用语言是什么？
- [ ] 关键概念是什么？
- [ ] 子域有哪些？
- [ ] 哪个是核心域？
- [ ] 跨域依赖是什么？
- [ ] 内部内聚性高吗？
- [ ] 边界清晰吗？
对于内聚性分析：
- [ ] 计算内聚性分数
- [ ] 识别低内聚性区域
- [ ] 映射跨域依赖
- [ ] 标记语言不匹配
- [ ] 注意紧密耦合
- [ ] 建议边界澄清
快速参考
子域决策树
Analyze business capability
└─ Is it a competitive advantage?
├─ YES → Core Domain
└─ NO → Is it business-specific?
├─ YES → Supporting Subdomain
└─ NO → Generic Subdomain
内聚性快速检查
Same vocabulary? → High linguistic cohesion
Used together? → High usage cohesion
Direct relationships? → High data cohesion
Change together? → High change cohesion
All high → Strong subdomain candidate
Mix of high/low → Review boundaries
All low → Likely wrong grouping
有界上下文信号
Clear boundary signs:
✅ Distinct Ubiquitous Language
✅ Concepts have unambiguous meaning
✅ Different meanings across contexts
✅ Clear integration points
Unclear boundary signs:
❌ Same terms with same meanings everywhere
❌ Concepts used identically across system
❌ No clear linguistic differences
❌ Tight coupling everywhere
避免的反模式
大泥球
- 一切连接到一切
- 无清晰边界
- 混合词汇
- 预防：明确的有界上下文
全包模型
- 整个业务的单一模型
- 不可能的全局部义
- 产生冲突
- 预防：拥抱多上下文
混合语言概念
- 同一上下文中不同词汇
- 示例：User/Permission与Forum/Post
- 预防：保持语言关联
备注
- 这是战略分析，非战术实施
- 专注于存在什么域，而非如何实施
- 有些跨域依赖是正常的
- 低内聚性不总是“坏”，它意味着“需要关注”
- 通用子域自然有较低内聚性
- 尽可能与领域专家验证
验证标准
良好的域识别具有：
- ✅ 具有独特通用语言的清晰边界
- ✅ 域内高内部内聚性
- ✅ 明确跨域依赖
- ✅ 与业务能力对齐
- ✅ 针对问题的可操作建议