⚡

子域识别与有界上下文分析Skill domain-analysis

这个技能用于分析代码库，根据领域驱动设计（DDD）的战略设计原则，识别核心、支持和通用子域，并映射有界上下文。适用于分析领域边界、分类子域、评估域内聚性、检测耦合问题等场景。关键词：DDD，领域驱动设计，子域，有界上下文，战略设计，域分析。

架构设计 0 次安装 0 次浏览 更新于 3/22/2026

name: 域分析 description: 在任何代码库中识别子域并建议有界上下文，遵循DDD战略设计。适用于分析领域边界、识别业务子域、评估域内聚性、映射有界上下文，或当用户询问DDD战略设计、域分析或子域分类时使用。 license: MIT metadata: version: “1.0.0” domain: 架构 triggers: DDD，领域驱动设计，子域，有界上下文，战略设计，域分析 role: 架构师 scope: 系统设计 output-format: 架构 related-skills: 架构模式，cqrs实现，事件溯源架构

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

这个技能分析代码库，以识别子域（核心、支持、通用）并遵循领域驱动设计战略设计原则建议有界上下文。

何时使用

在以下情况应用此技能：

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

核心原则

子域分类

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

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

支持子域：必需但非差异化，业务特定

  • 指标：支持核心域，中等复杂度，业务特定规则

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

  • 指标：易于理解的问题，低差异化，标准功能

有界上下文

一个明确的语言边界，其中领域术语具有特定、无歧义的含义。

  • 主要性质：语言边界，非技术
  • 关键规则：在边界内，所有通用语言术语均无歧义
  • 目标：理想情况下，将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 → 身份语言

语言边界

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

概念关系

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

阶段3：识别子域

子域具有：

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

常见域模式：

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

分类每个子域：

使用此决策树：

它是竞争优势吗？
  是 → 核心域
  否 → 是否需要业务特定知识？
        是 → 支持子域
        否 → 通用子域

阶段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：映射有界上下文

对于每个识别的子域，建议有界上下文：

有界上下文特征：

  • 名称反映通用语言
  • 包含完整的域模型
  • 具有明确的集成点
  • 清晰的语言边界

集成模式：

  • 共享内核：上下文之间共享模型（谨慎使用）
  • 客户/供应商：下游依赖于上游
  • 顺从者：下游顺从上游
  • 反腐败层：上下文之间的翻译层
  • 开放主机服务：用于集成的发布接口
  • 发布语言：良好记录的集成协议

输出格式

域地图

对于每个域/子域：

## 域：{名称}

**类型**：核心域 | 支持子域 | 通用子域

**通用语言**：{关键业务术语}

**业务能力**：{解决的业务问题}

**关键概念**：

- {概念} (实体|服务|用例) - {简要描述}

**子域**（如果适用）：

1. {子域} (核心|支持|通用)
   - 概念：{列表}
   - 内聚性：{得分}/10
   - 依赖：→ {其他域}

**建议有界上下文**：{名称}上下文

- 语言边界：{术语具有特定含义的地方}
- 集成：{如何与其他上下文集成}

**依赖**：

- → {其他域} 通过 {接口/API}
- ← {其他域} 通过 {接口/API}

**内聚性得分**：{得分}/10

内聚性矩阵

## 跨域内聚性

| 域A | 域B | 内聚性 | 问题              | 推荐          |
| -------- | -------- | -------- | ------------------ | ----------------------- |
| 计费 | 身份 | 2/10     | ❌ 直接耦合 | 使用接口           |
| 内容 | 计费 | 6/10     | ⚠️ 使用跟踪  | 基于事件的集成 |

低内聚性报告

## 检测到的问题

### 优先级：高

**问题**：{描述}

- **位置**：{文件/类/方法}
- **问题**：{错误之处}
- **概念**：{涉及的概念}
- **内聚性**：{得分}/10
- **推荐**：{建议修复}

### 优先级：中等

{类似格式}

有界上下文地图

## 建议有界上下文

### {上下文名称}上下文

**包含子域**：

- {子域1} (核心)
- {子域2} (支持)

**通用语言**：

- 术语：在此上下文中的定义

**集成要求**：

- 从消费：{其他上下文} 通过 {模式}
- 发布到：{其他上下文} 通过 {模式}

**实现说明**：

- 分离持久性
- 独立部署
- 明确的API边界

最佳实践

要做 ✅

  • 聚焦业务语言，而非代码结构
  • 让通用语言指导边界
  • 客观测量内聚性
  • 识别清晰的集成点
  • 分类每个子域（核心/支持/通用）
  • 首先寻找语言边界

不要 ❌

  • 不要按技术层分组
  • 不要强制单一全局模型
  • 不要忽视语言差异
  • 不要直接耦合域
  • 不要通过架构创建上下文
  • 不要消除所有依赖（有些是必要的）

分析清单

对于每个概念：

  • [ ] 属于哪种业务语言？
  • [ ] 是哪个域/子域的一部分？
  • [ ] 是核心、支持还是通用？
  • [ ] 与哪些其他概念相关？
  • [ ] 依赖是否在相同域内？
  • [ ] 有任何语言不匹配吗？

对于每个域：

  • [ ] 通用语言是什么？
  • [ ] 关键概念是什么？
  • [ ] 子域是什么？
  • [ ] 哪个是核心域？
  • [ ] 跨域依赖是什么？
  • [ ] 内部内聚性高吗？
  • [ ] 边界清晰吗？

对于内聚性分析：

  • [ ] 计算内聚性得分
  • [ ] 识别低内聚区域
  • [ ] 映射跨域依赖
  • [ ] 标记语言不匹配
  • [ ] 注意紧耦合
  • [ ] 建议边界澄清

快速参考

子域决策树

分析业务能力
└─ 是竞争优势吗？
   ├─ 是 → 核心域
   └─ 否 → 是否需要业务特定知识？
      ├─ 是 → 支持子域
      └─ 否 → 通用子域

内聚性快速检查

相同词汇？ → 高语言内聚性
一起使用？ → 高使用内聚性
直接关系？ → 高数据内聚性
一起更改？ → 高更改内聚性

全部高 → 强子域候选
混合高/低 → 检查边界
全部低 → 可能分组错误

有界上下文信号

清晰边界迹象：
✅ 独特的通用语言
✅ 概念含义无歧义
✅ 不同上下文中有不同含义
✅ 清晰的集成点

不清晰边界迹象：
❌ 所有地方相同术语有相同含义
❌ 概念在系统中相同使用
❌ 无清晰语言差异
❌ 到处紧耦合

要避免的反模式

大泥球

  • 一切相互连接
  • 无清晰边界
  • 混合词汇
  • 预防：明确的有界上下文

全包容模型

  • 整个业务的单一模型
  • 不可能的全局定义
  • 导致冲突
  • 预防：接受多个上下文

混合语言概念

  • 同一上下文中的不同词汇
  • 示例：用户/权限与论坛/帖子
  • 预防：保持语言关联

注意事项

  • 这是战略分析，非战术实现
  • 关注存在哪些域，而非如何实现
  • 某些跨域依赖是正常的
  • 低内聚性不一定意味着“坏”，它意味着“需要关注”
  • 通用子域自然具有较低内聚性
  • 尽可能与领域专家验证

验证标准

良好的域识别具有：

  • ✅ 具有独特通用语言的清晰边界
  • ✅ 域内高内部内聚性
  • ✅ 明确的跨域依赖
  • ✅ 与能力业务对齐
  • ✅ 针对问题的可操作推荐