domain-analysis

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Subdomain Identification & Bounded Context Analysis

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

This skill analyzes codebases to identify subdomains (Core, Supporting, Generic) and suggest bounded contexts following Domain-Driven Design Strategic Design principles.

此技能遵循领域驱动设计（Domain-Driven Design）战略设计原则，分析代码库以识别子域（核心、支撑、通用）并建议限界上下文。

When to Use

使用场景

Apply this skill when:

Analyzing domain boundaries in any codebase
Identifying Core, Supporting, and Generic subdomains
Mapping bounded contexts from problem space to solution space
Assessing domain cohesion and detecting coupling issues
Planning domain-driven refactoring
Understanding business capabilities in code

当您需要以下操作时应用此技能：

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

Core Principles

核心原则

Subdomain Classification

子域分类

Core Domain: Competitive advantage, highest business value, requires best developers

Indicators: Complex business logic, frequent changes, domain experts needed

Supporting Subdomain: Essential but not differentiating, business-specific

Indicators: Supports Core Domain, moderate complexity, business-specific rules

Generic Subdomain: Common functionality, could be outsourced

Indicators: Well-understood problem, low differentiation, standard functionality

Core Domain（核心子域）：具备竞争优势，业务价值最高，需要最优秀的开发人员

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

Supporting Subdomain（支撑子域）：必不可少但不具备差异化，具有业务特异性

指标：支撑Core Domain、中等复杂度、业务特定规则

Generic Subdomain（通用子域）：通用功能，可外包

指标：问题清晰易懂、差异化低、标准化功能

Bounded Context

Bounded Context（限界上下文）

An explicit linguistic boundary where domain terms have specific, unambiguous meanings.

Primary nature: Linguistic boundary, not technical
Key rule: Inside boundary, all Ubiquitous Language terms are unambiguous
Goal: Align 1 subdomain to 1 bounded context (ideal)

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

本质：语言边界，而非技术边界
关键规则：边界内，所有Ubiquitous Language（通用语言）术语均无歧义
目标：理想情况下，1个子域对应1个限界上下文

Analysis Process

分析流程

Phase 1: Extract Concepts

阶段1：提取概念

Scan codebase for business concepts (not infrastructure):

Entities (domain models with identity)
- Patterns:
```
@Entity
```
  ,
```
class
```
  , domain models
- Focus: Business concepts, not technical classes
Services (business operations)
- Patterns:
```
*Service
```
  ,
```
*Manager
```
  ,
```
*Handler
```
- Focus: Business logic, not technical utilities
Use Cases (business workflows)
- Patterns:
```
*UseCase
```
  ,
```
*Command
```
  ,
```
*Handler
```
- Focus: Business processes, not CRUD
Controllers/Resolvers (entry points)
- Patterns:
```
*Controller
```
  ,
```
*Resolver
```
  , API endpoints
- Focus: Business capabilities, not technical routes

扫描代码库中的业务概念（非基础设施相关）：

Entities（实体）（带身份标识的领域模型）
- 模式：
```
@Entity
```
  、
```
class
```
  、领域模型
- 重点：业务概念，而非技术类
Services（服务）（业务操作）
- 模式：
```
*Service
```
  、
```
*Manager
```
  、
```
*Handler
```
- 重点：业务逻辑，而非技术工具
Use Cases（用例）（业务流程）
- 模式：
```
*UseCase
```
  、
```
*Command
```
  、
```
*Handler
```
- 重点：业务流程，而非CRUD操作
Controllers/Resolvers（控制器/解析器）（入口点）
- 模式：
```
*Controller
```
  、
```
*Resolver
```
  、API端点
- 重点：业务能力，而非技术路由

Phase 2: Group by Ubiquitous Language

阶段2：按通用语言分组

For each concept, determine:

Primary Language Context

What business vocabulary does this belong to?
Examples:
- ```
Subscription
```
  ,
```
Invoice
```
  ,
```
Payment
```
  → Billing language
- ```
Movie
```
  ,
```
Video
```
  ,
```
Episode
```
  → Content language
- ```
User
```
  ,
```
Authentication
```
  → Identity language

Linguistic Boundaries

Where do term meanings change?
Same term, different meaning = different bounded context
Example: "Customer" in Sales vs "Customer" in Support

Concept Relationships

Which concepts naturally belong together?
Which share business vocabulary?
Which reference each other?

针对每个概念，确定：

主要语言上下文

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

语言边界

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

概念关系

哪些概念自然归为一组？
哪些共享业务词汇？
哪些互相引用？

Phase 3: Identify Subdomains

阶段3：识别子域

A subdomain has:

Distinct business capability
Independent business value
Unique vocabulary
Multiple related entities working together
Cohesive set of business operations

Common Domain Patterns:

Billing/Subscription: Payments, invoices, plans
Content/Catalog: Media, products, inventory
Identity/Access: Users, authentication, authorization
Analytics: Metrics, dashboards, insights
Notifications: Messages, alerts, communications

Classify Each Subdomain:

Use this decision tree:

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

子域具备以下特征：

独特的业务能力
独立的业务价值
专属词汇
多个相关实体协同工作
内聚的业务操作集合

常见领域模式：

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

子域分类：

使用如下决策树：

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

Phase 4: Assess Cohesion

阶段4：评估内聚性

High Cohesion Indicators ✅

Concepts share Ubiquitous Language
Concepts frequently used together
Direct business relationships
Changes to one affect others in group
Solve same business problem

Low Cohesion Indicators ❌

Different business vocabularies mixed
Concepts rarely used together
No direct business relationship
Changes don't affect others
Solve different business problems

Cohesion Score Formula:

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 ❌

高内聚指标 ✅

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

低内聚指标 ❌

混合不同业务词汇
概念极少一起使用
无直接业务关系
变更不会影响其他概念
解决不同业务问题

内聚性评分公式：

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 ❌

Phase 5: Detect Low Cohesion Issues

阶段5：检测低内聚问题

Rule 1: Linguistic Mismatch

Problem: Different business vocabularies mixed
Example:
```
User
```
(identity) +
```
Subscription
```
(billing) in same service
Action: Suggest separation into different bounded contexts

Rule 2: Cross-Domain Dependencies

Problem: Tight coupling between domains
Example: Service A directly instantiates entities from Domain B
Action: Suggest interface-based integration

Rule 3: Mixed Responsibilities

Problem: Single class handles multiple business concerns
Example: Service handling both billing and content
Action: Suggest splitting by subdomain

Rule 4: Generic in Core

Problem: Generic functionality in core business logic
Example: Email sending in billing service
Action: Extract to Generic Subdomain

Rule 5: Unclear Boundaries

Problem: Cannot determine which domain concept belongs to
Example: Entity with relationships to multiple domains
Action: Clarify boundaries, possibly split concept

规则1：语言不匹配

问题：混合不同业务词汇
示例：同一服务中包含
```
User
```
（身份）和
```
Subscription
```
（计费）
行动：建议拆分到不同限界上下文

规则2：跨域依赖

问题：领域间紧密耦合
示例：服务A直接实例化领域B的实体
行动：建议基于接口的集成

规则3：职责混合

问题：单个类处理多个业务关注点
示例：同时处理计费和内容的服务
行动：建议按子域拆分

规则4：核心域中包含通用功能

问题：核心业务逻辑中包含通用功能
示例：计费服务中包含邮件发送功能
行动：提取到Generic Subdomain

规则5：边界模糊

问题：无法确定概念所属领域
示例：与多个领域存在关联的实体
行动：明确边界，可能拆分概念

Phase 6: Map Bounded Contexts

阶段6：映射限界上下文

For each subdomain identified, suggest bounded context:

Bounded Context Characteristics:

Name reflects Ubiquitous Language
Contains complete domain model
Has explicit integration points
Clear linguistic boundary

Integration Patterns:

Shared Kernel: Shared model between contexts (use sparingly)
Customer/Supplier: Downstream depends on upstream
Conformist: Downstream conforms to upstream
Anti-corruption Layer: Translation layer between contexts
Open Host Service: Published interface for integration
Published Language: Well-documented integration protocol

针对每个识别出的子域，建议对应的限界上下文：

限界上下文特征：

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

集成模式：

Shared Kernel（共享内核）：上下文间共享模型（谨慎使用）
Customer/Supplier（客户/供应商）：下游依赖上游
Conformist（遵循者）：下游遵循上游规范
Anti-corruption Layer（防腐层）：上下文间的转换层
Open Host Service（开放主机服务）：发布用于集成的接口
Published Language（发布语言）：文档完善的集成协议

Output Format

输出格式

Domain Map

领域映射

For each domain/subdomain:

markdown

undefined

针对每个领域/子域：

markdown

undefined

Domain: {Name}

领域：{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):

{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

undefined

类型：Core Domain | Supporting Subdomain | Generic Subdomain

通用语言：{key business terms}

业务能力：{what business problem it solves}

核心概念:

{Concept} (Entity|Service|UseCase) - {brief description}

子域（如有）:

{Subdomain} (Core|Supporting|Generic)
- 概念：{list}
- 内聚性：{score}/10
- 依赖：→ {other domains}

建议限界上下文：{Name}Context

语言边界：{where terms have specific meaning}
集成方式：{how it should integrate with other contexts}

依赖关系:

→ {OtherDomain} via {interface/API}
← {OtherDomain} via {interface/API}

内聚性评分：{score}/10

undefined

Cohesion Matrix

内聚性矩阵

markdown

undefined

markdown

undefined

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

undefined

领域A	领域B	内聚性	问题	建议方案
Billing	Identity	2/10	❌ 直接耦合	使用接口
Content	Billing	6/10	⚠️ 使用追踪	基于事件的集成

undefined

Low Cohesion Report

低内聚问题报告

markdown

undefined

markdown

undefined

Issues Detected

检测到的问题

Priority: High

优先级：高

Issue: {description}

Location: {file/class/method}
Problem: {what's wrong}
Concepts: {involved concepts}
Cohesion: {score}/10
Recommendation: {suggested fix}

问题：{description}

位置：{file/class/method}
问题说明：{what's wrong}
涉及概念：{involved concepts}
内聚性：{score}/10
建议修复：{suggested fix}

Priority: Medium

优先级：中

{similar format}

undefined

{similar format}

undefined

Bounded Context Map

限界上下文映射

markdown

undefined

markdown

undefined

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

undefined

包含子域:

{Subdomain1} (Core)
{Subdomain2} (Supporting)

通用语言:

术语：此上下文中的定义

集成要求:

消费自：{OtherContext} via {pattern}
发布至：{OtherContext} via {pattern}

实现注意事项:

独立持久化
独立部署
明确的API边界

undefined

Best Practices

最佳实践

Do's ✅

Don'ts ❌

不推荐做法 ❌

Don't group by technical layers
Don't force single global model
Don't ignore linguistic differences
Don't couple domains directly
Don't create contexts by architecture
Don't eliminate all dependencies (some are necessary)

不要按技术层分组
不要强制单一全局模型
不要忽略语言差异
不要直接耦合领域
不要按架构划分上下文
不要消除所有依赖（部分依赖是必要的）

Analysis Checklist

分析检查清单

Quick Reference

快速参考

Subdomain Decision Tree

子域决策树

Analyze business capability
└─ Is it competitive advantage?
   ├─ YES → Core Domain
   └─ NO → Is it business-specific?
      ├─ YES → Supporting Subdomain
      └─ NO → Generic Subdomain

Analyze business capability
└─ Is it competitive advantage?
   ├─ YES → Core Domain
   └─ NO → Is it business-specific?
      ├─ YES → Supporting Subdomain
      └─ NO → Generic Subdomain

Cohesion Quick Check

内聚性快速检查

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

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

Bounded Context Signals

限界上下文信号

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

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

Anti-Patterns to Avoid

需避免的反模式

Big Ball of Mud

Everything connected to everything
No clear boundaries
Mixed vocabularies
Prevention: Explicit bounded contexts

All-Inclusive Model

Single model for entire business
Impossible global definitions
Creates conflicts
Prevention: Embrace multiple contexts

Mixed Linguistic Concepts

Different vocabularies in same context
Example: User/Permission with Forum/Post
Prevention: Keep linguistic associations

大泥球（Big Ball of Mud）

所有组件互相连接
无清晰边界
混合多种词汇
预防：明确限界上下文

全包模型（All-Inclusive Model）

单一模型覆盖整个业务
无法实现全局定义
引发冲突
预防：接受多上下文模式

混合语言概念（Mixed Linguistic Concepts）

同一上下文中混合不同词汇
示例：User/Permission与Forum/Post共存
预防：保持语言关联性

Notes

注意事项

This is strategic analysis, not tactical implementation
Focus on WHAT domains exist, not HOW to implement
Some cross-domain dependencies are normal
Low cohesion doesn't always mean "bad," it means "needs attention"
Generic Subdomains naturally have lower cohesion
Always validate with domain experts when possible

这是战略分析，而非战术实现
关注“存在哪些领域”，而非“如何实现”
部分跨域依赖是正常的
低内聚并不总是意味着“不好”，而是“需要关注”
Generic Subdomain自然具有较低的内聚性
尽可能与领域专家验证分析结果

Validation Criteria

验证标准

Good domain identification has:

✅ Clear boundaries with distinct Ubiquitous Language
✅ High internal cohesion within domains
✅ Explicit cross-domain dependencies
✅ Business alignment with capabilities
✅ Actionable recommendations for issues

优质的领域识别应具备：

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

domain-analysis

Original

Translation

Subdomain Identification & Bounded Context Analysis

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

When to Use

使用场景

Core Principles

核心原则

Subdomain Classification

子域分类

Bounded Context

Bounded Context（限界上下文）

Analysis Process

分析流程

Phase 1: Extract Concepts

阶段1：提取概念

Phase 2: Group by Ubiquitous Language

阶段2：按通用语言分组

Phase 3: Identify Subdomains

阶段3：识别子域

Phase 4: Assess Cohesion

阶段4：评估内聚性

Phase 5: Detect Low Cohesion Issues

阶段5：检测低内聚问题

Phase 6: Map Bounded Contexts

阶段6：映射限界上下文

Output Format

输出格式

Domain Map

领域映射

Domain: {Name}

领域：{Name}

Cohesion Matrix

内聚性矩阵

Cross-Domain Cohesion

跨域内聚性

Low Cohesion Report

低内聚问题报告

Issues Detected

检测到的问题

Priority: High

优先级：高

Priority: Medium

优先级：中

Bounded Context Map

限界上下文映射

Suggested Bounded Contexts

建议的限界上下文

{ContextName}Context

{ContextName}Context

Best Practices

最佳实践

Do's ✅

推荐做法 ✅

Don'ts ❌

不推荐做法 ❌

Analysis Checklist

分析检查清单

Quick Reference

快速参考

Subdomain Decision Tree

子域决策树

Cohesion Quick Check

内聚性快速检查

Bounded Context Signals

限界上下文信号

Anti-Patterns to Avoid

需避免的反模式

Notes

注意事项

Validation Criteria

验证标准