domain-analysis

子域识别与限界上下文分析

此技能会分析代码库，以识别子域（核心、支撑、通用），并根据领域驱动设计战略设计原则提出限界上下文建议。

使用时机

在以下情况下应用此技能：

• 分析任何代码库中的领域边界
• 识别核心、支撑和通用子域
• 将限界上下文从问题空间映射到解决方案空间
• 评估领域内聚性并检测耦合问题
• 规划领域驱动的重构
• 理解代码中的业务能力

核心原则

子域分类

核心域：竞争优势、最高业务价值，需要最优秀的开发人员

• 指标：复杂的业务逻辑、频繁变更、需要领域专家

支撑子域：不可或缺但不具差异化，特定于业务

• 指标：支持核心域、中等复杂度、业务专属规则

通用子域：常见功能，可外包

• 指标：已充分理解的问题、差异化程度低、标准功能

限界上下文

明确的语言边界，领域术语在其中具有特定且明确的含义。

• 主要性质：语言边界，而非技术边界
• 关键规则：在边界内，所有通用语言术语都含义明确
• 目标：1 个子域对应 1 个限界上下文（理想情况）

分析流程

阶段 1：提取概念

扫描代码库，查找业务概念（而非基础设施）：

1. 实体（具有标识的领域模型）

   • 模式：@Entity、class、领域模型
   • 重点：业务概念，而非技术类

2. 服务（业务操作）

   • 模式：*Service、*Manager、*Handler
   • 重点：业务逻辑，而非技术工具

3. 用例（业务工作流）

   • 模式：*UseCase、*Command、*Handler
   • 重点：业务流程，而非 CRUD

4. 控制器/解析器（入口点）

   • 模式：*Controller、*Resolver、API 端点
   • 重点：业务能力，而非技术路由

阶段 2：按通用语言分组

对于每个概念，确定：

主要语言上下文

• 它属于哪种业务词汇？
• 示例：
  • Subscription、Invoice、Payment → 计费语言
  • Movie、Video、Episode → 内容语言
  • User、Authentication → 身份语言

语言边界

• 术语的含义在哪里发生变化？
• 同一术语，含义不同 = 不同的限界上下文
• 示例：销售中的“Customer”与支持中的“Customer”

概念关系

• 哪些概念自然地属于一起？
• 哪些共享业务词汇？
• 哪些相互引用？

阶段 3：识别子域

子域具备以下特征：

• 独特的业务能力
• 独立的业务价值
• 独特的词汇
• 多个相关实体协同工作
• 内聚的一组业务操作

常见领域模式：

• 计费/订阅：付款、发票、套餐
• 内容/目录：媒体、产品、库存
• 身份/访问：用户、身份验证、授权
• 分析：指标、仪表板、洞察
• 通知：消息、提醒、通信

对子域进行分类：

使用此决策树：

Is it a competitive advantage?
  YES → Core Domain
  NO → Does it require business-specific knowledge?
        YES → Supporting Subdomain
        NO → Generic Subdomain

阶段 4：评估内聚性

高内聚性指标 ✅

• 概念共享通用语言
• 概念经常一起使用
• 存在直接的业务关系
• 对一个概念的变更会影响组内其他概念
• 解决同一业务问题

低内聚性指标 ❌

• 混杂不同的业务词汇
• 概念很少一起使用
• 不存在直接的业务关系
• 变更不会影响其他概念
• 解决不同的业务问题

内聚性评分公式：

Score = (
  Linguistic Cohesion (0-3) +    // Shared vocabulary
  Usage Cohesion (0-3) +         // Used together
  Data Cohesion (0-2) +          // Entity relationships
  Change Cohesion (0-2)          // Change together
) / 10

8-10: High Cohesion ✅
5-7:  Medium Cohesion ⚠️
0-4:  Low Cohesion ❌

阶段 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 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 混在一起
• 预防方法：保持语言关联

注意事项

• 这是战略分析，而非战术实现
• 重点关注存在哪些领域，而非如何实现
• 存在一些跨领域依赖是正常的
• 内聚性低并不总是意味着“糟糕”，而是意味着“需要关注”
• 通用子领域的内聚性通常较低
• 条件允许时，务必向领域专家核实

验证标准

良好的领域识别应具备：

• ✅ 边界清晰，且具有独特的通用语言
• ✅ 领域内部内聚性高
• ✅ 明确的跨领域依赖
• ✅ 业务与能力相匹配
• ✅ 针对问题提出可执行的建议