domain-identification-grouping
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseDomain Identification and Grouping
领域识别与分组
This skill groups architectural components into logical domains (business areas) to prepare for creating domain services in a service-based architecture.
该技能将架构组件划分为逻辑领域(业务领域),为在service-based architecture中创建领域服务做准备。
How to Use
使用方法
Quick Start
快速入门
Request analysis of your codebase:
- "Group components into logical domains"
- "Identify component domains for service-based architecture"
- "Create domain groupings from components"
- "Analyze which components belong to which domains"
请求分析您的代码库:
- "将组件划分为逻辑领域"
- "为service-based architecture识别组件领域"
- "从组件创建领域分组"
- "分析组件所属领域"
Usage Examples
使用示例
Example 1: Domain Identification
User: "Group components into logical domains"
The skill will:
1. Analyze component responsibilities and relationships
2. Identify business domains based on functionality
3. Group components into domains
4. Create domain diagrams
5. Suggest namespace refactoring for domain alignmentExample 2: Domain Analysis
User: "Which domain should the billing components belong to?"
The skill will:
1. Analyze billing component functionality
2. Check relationships with other components
3. Identify appropriate domain (e.g., Customer or Financial)
4. Recommend domain assignmentExample 3: Domain Refactoring
User: "What namespace refactoring is needed to align components with domains?"
The skill will:
1. Compare current component namespaces to identified domains
2. Identify misaligned components
3. Suggest namespace changes
4. Create refactoring plan示例1:领域识别
用户:"将组件划分为逻辑领域"
该技能将:
1. 分析组件职责与关系
2. 根据功能识别业务领域
3. 将组件分组到对应领域
4. 创建领域图
5. 建议通过命名空间重构实现领域对齐示例2:领域分析
用户:"计费组件应属于哪个领域?"
该技能将:
1. 分析计费组件功能
2. 检查与其他组件的关系
3. 确定合适的领域(例如客户领域或财务领域)
4. 推荐领域分配方案示例3:领域重构
用户:"需要进行哪些命名空间重构以实现组件与领域对齐?"
该技能将:
1. 对比当前组件命名空间与已识别的领域
2. 识别未对齐的组件
3. 建议命名空间变更方案
4. 创建重构计划Step-by-Step Process
分步流程
- Identify Domains: Analyze business capabilities and component relationships
- Group Components: Assign components to appropriate domains
- Validate Groupings: Ensure components fit well in their domains
- Refactor Namespaces: Align component namespaces with domains
- Create Domain Map: Visualize domain structure and component groupings
- 识别领域:分析业务能力与组件关系
- 分组组件:将组件分配到合适的领域
- 验证分组:确保组件与所属领域匹配度良好
- 重构命名空间:调整组件命名空间以匹配领域
- 创建领域映射:可视化领域结构与组件分组
When to Use
适用场景
Apply this skill when:
- After identifying, sizing, and analyzing component dependencies
- Before creating domain services (Pattern 6)
- When planning service-based architecture migration
- Analyzing component relationships and business alignment
- Preparing for domain-driven design implementation
- Grouping components for better organization
在以下场景中应用该技能:
- 完成组件依赖识别、评估与分析后
- 创建领域服务(模式6)之前
- 规划service-based architecture迁移时
- 分析组件关系与业务对齐情况时
- 准备实施领域驱动设计时
- 为优化组织方式对组件进行分组时
Core Concepts
核心概念
Domain Definition
领域定义
A domain is a logical grouping of components that:
- Represents a distinct business capability or area
- Contains related components that work together
- Has clear boundaries and responsibilities
- Can become a domain service in service-based architecture
Examples:
- Customer Domain: Customer profile, billing, support contracts
- Ticketing Domain: Ticket creation, assignment, routing, completion
- Reporting Domain: Ticket reports, expert reports, financial reports
领域是组件的逻辑分组,需满足:
- 代表独立的业务能力或领域
- 包含协同工作的相关组件
- 具有清晰的边界与职责
- 可在service-based architecture中成为领域服务
示例:
- 客户领域:客户档案、计费、支持合同
- 工单领域:工单创建、分配、路由、完成
- 报表领域:工单报表、专家报表、财务报表
Component Domain Relationship
组件-领域关系
One-to-Many: A single domain contains multiple components
Domain: Customer
├── Component: Customer Profile
├── Component: Billing Payment
├── Component: Billing History
└── Component: Support Contract一对多:单个领域包含多个组件
领域: 客户
├── 组件: 客户档案
├── 组件: 计费支付
├── 组件: 计费历史
└── 组件: 支持合同Domain Manifestation
领域的物理体现
Domains are physically manifested through namespace structure:
Before Domain Alignment:
services/billing/payment
services/billing/history
services/customer/profile
services/supportcontractAfter Domain Alignment:
services/customer/billing/payment
services/customer/billing/history
services/customer/profile
services/customer/supportcontractNotice how all customer-related functionality is grouped under domain.
.customer领域通过命名空间结构物理体现:
领域对齐前:
services/billing/payment
services/billing/history
services/customer/profile
services/supportcontract领域对齐后:
services/customer/billing/payment
services/customer/billing/history
services/customer/profile
services/customer/supportcontract注意所有客户相关功能如何归到领域下。
.customerAnalysis Process
分析流程
Phase 1: Identify Business Domains
阶段1:识别业务领域
Analyze the codebase to identify distinct business domains:
-
Examine Component Responsibilities
- Read component names and descriptions
- Understand what each component does
- Identify business capabilities
-
Look for Business Language
- Group components by business vocabulary
- Example: "billing", "payment", "invoice" → Financial domain
- Example: "customer", "profile", "contract" → Customer domain
-
Identify Domain Boundaries
- Where do business concepts change?
- What are the distinct business areas?
- How do components relate to business capabilities?
-
Collaborate with Business Stakeholders
- Validate domain identification with product owners
- Ensure domains align with business understanding
- Get feedback on domain boundaries
Example Domain Identification:
markdown
undefined分析代码库以识别独立的业务领域:
-
检查组件职责
- 阅读组件名称与描述
- 理解每个组件的功能
- 识别业务能力
-
寻找业务语言
- 按业务词汇对组件分组
- 示例:"billing"、"payment"、"invoice" → 财务领域
- 示例:"customer"、"profile"、"contract" → 客户领域
-
识别领域边界
- 业务概念的分界点在哪里?
- 有哪些独立的业务领域?
- 组件如何与业务能力关联?
-
与业务利益相关者协作
- 与产品负责人验证领域识别结果
- 确保领域与业务认知对齐
- 获取关于领域边界的反馈
领域识别示例:
markdown
undefinedIdentified Domains
已识别领域
-
Ticketing Domain (ss.ticket)
- Ticket creation, assignment, routing, completion
- Customer surveys
- Knowledge base
-
Customer Domain (ss.customer)
- Customer profile
- Billing and payment
- Support contracts
-
Reporting Domain (ss.reporting)
- Ticket reports
- Expert reports
- Financial reports
-
Admin Domain (ss.admin)
- User maintenance
- Expert profile management
-
Shared Domain (ss.shared)
- Login
- Notification
undefined-
工单领域 (ss.ticket)
- 工单创建、分配、路由、完成
- 客户调查
- 知识库
-
客户领域 (ss.customer)
- 客户档案
- 计费与支付
- 支持合同
-
报表领域 (ss.reporting)
- 工单报表
- 专家报表
- 财务报表
-
管理领域 (ss.admin)
- 用户维护
- 专家档案管理
-
共享领域 (ss.shared)
- 登录
- 通知
undefinedPhase 2: Group Components into Domains
阶段2:将组件分组到领域
Assign each component to an appropriate domain:
-
Analyze Component Functionality
- What business capability does it support?
- What domain vocabulary does it use?
- What other components does it relate to?
-
Check Component Relationships
- Which components are frequently used together?
- What are the dependencies between components?
- Do components share data or workflows?
-
Assign to Domain
- Place component in domain that best fits its functionality
- Ensure component aligns with domain's business language
- Verify component relationships support domain grouping
-
Handle Edge Cases
- Components that don't fit clearly: Analyze more deeply
- Components that fit multiple domains: Choose primary domain
- Shared components: May belong to Shared domain
Example Component Grouping:
markdown
undefined将每个组件分配到合适的领域:
-
分析组件功能
- 它支持哪些业务能力?
- 使用了哪些领域词汇?
- 与其他组件有哪些关联?
-
检查组件关系
- 哪些组件经常一起使用?
- 组件之间有哪些依赖?
- 组件是否共享数据或工作流?
-
分配到领域
- 将组件放置到最符合其功能的领域
- 确保组件与领域的业务语言对齐
- 验证组件关系支持领域分组
-
处理边缘情况
- 无法明确归类的组件:深入分析
- 适合多个领域的组件:选择主领域
- 共享组件:可归到共享领域
组件分组示例:
markdown
undefinedComponent Domain Assignment
组件-领域分配
Ticketing Domain (ss.ticket)
工单领域 (ss.ticket)
- Ticket Shared (ss.ticket.shared)
- Ticket Maintenance (ss.ticket.maintenance)
- Ticket Completion (ss.ticket.completion)
- Ticket Assign (ss.ticket.assign)
- Ticket Route (ss.ticket.route)
- KB Maintenance (ss.ticket.kb.maintenance)
- KB Search (ss.ticket.kb.search)
- Survey (ss.ticket.survey)
- Ticket Shared (ss.ticket.shared)
- Ticket Maintenance (ss.ticket.maintenance)
- Ticket Completion (ss.ticket.completion)
- Ticket Assign (ss.ticket.assign)
- Ticket Route (ss.ticket.route)
- KB Maintenance (ss.ticket.kb.maintenance)
- KB Search (ss.ticket.kb.search)
- Survey (ss.ticket.survey)
Customer Domain (ss.customer)
客户领域 (ss.customer)
- Customer Profile (ss.customer.profile)
- Billing Payment (ss.customer.billing.payment)
- Billing History (ss.customer.billing.history)
- Support Contract (ss.customer.supportcontract)
- Customer Profile (ss.customer.profile)
- Billing Payment (ss.customer.billing.payment)
- Billing History (ss.customer.billing.history)
- Support Contract (ss.customer.supportcontract)
Reporting Domain (ss.reporting)
报表领域 (ss.reporting)
- Reporting Shared (ss.reporting.shared)
- Ticket Reports (ss.reporting.tickets)
- Expert Reports (ss.reporting.experts)
- Financial Reports (ss.reporting.financial)
undefined- Reporting Shared (ss.reporting.shared)
- Ticket Reports (ss.reporting.tickets)
- Expert Reports (ss.reporting.experts)
- Financial Reports (ss.reporting.financial)
undefinedPhase 3: Validate Domain Groupings
阶段3:验证领域分组
Ensure components fit well in their assigned domains:
-
Check Cohesion
- Do components in domain share business language?
- Are components frequently used together?
- Do components have direct relationships?
-
Verify Boundaries
- Are domain boundaries clear?
- Do components belong to only one domain?
- Are there components that don't fit anywhere?
-
Assess Completeness
- Are all components assigned to a domain?
- Are domains cohesive and well-formed?
- Do domains represent distinct business capabilities?
-
Get Stakeholder Validation
- Review domain groupings with product owners
- Ensure domains align with business understanding
- Get feedback on domain boundaries
Validation Checklist:
- All components assigned to a domain
- Domains have clear boundaries
- Components fit well in their domains
- Domains represent distinct business capabilities
- Stakeholders validate domain groupings
确保组件与分配的领域匹配度良好:
-
检查内聚性
- 领域内的组件是否共享业务语言?
- 组件是否经常一起使用?
- 组件之间是否有直接关系?
-
验证边界
- 领域边界是否清晰?
- 组件是否仅属于一个领域?
- 是否有组件无法归类?
-
评估完整性
- 所有组件是否都已分配到领域?
- 领域是否内聚且结构合理?
- 领域是否代表独立的业务能力?
-
获取利益相关者验证
- 与产品负责人审核领域分组
- 确保领域与业务认知对齐
- 获取关于领域边界的反馈
验证清单:
- 所有组件已分配到领域
- 领域边界清晰
- 组件与所属领域匹配度良好
- 领域代表独立的业务能力
- 利益相关者已验证领域分组
Phase 4: Refactor Namespaces for Domain Alignment
阶段4:重构命名空间以实现领域对齐
Align component namespaces with identified domains:
-
Compare Current vs Target Namespaces
- Current:
services/billing/payment - Target:
services/customer/billing/payment - Change: Add domain node
.customer
- Current:
-
Identify Refactoring Needed
- Which components need namespace changes?
- What domain nodes need to be added?
- Are there components already aligned?
-
Create Refactoring Plan
- List components needing namespace changes
- Specify target namespace for each
- Prioritize refactoring work
-
Execute Refactoring
- Update component namespaces
- Update imports/references
- Verify all references updated
Example Namespace Refactoring:
markdown
undefined调整组件命名空间以匹配已识别的领域:
-
对比当前与目标命名空间
- 当前:
services/billing/payment - 目标:
services/customer/billing/payment - 变更:添加领域节点
.customer
- 当前:
-
识别需要重构的内容
- 哪些组件需要变更命名空间?
- 需要添加哪些领域节点?
- 哪些组件已对齐?
-
创建重构计划
- 列出需要变更命名空间的组件
- 指定每个组件的目标命名空间
- 确定重构工作的优先级
-
执行重构
- 更新组件命名空间
- 更新导入/引用
- 验证所有引用已更新
命名空间重构示例:
markdown
undefinedNamespace Refactoring Plan
命名空间重构计划
Customer Domain Alignment
客户领域对齐
| Component | Current Namespace | Target Namespace | Action |
|---|---|---|---|
| Billing Payment | ss.billing.payment | ss.customer.billing.payment | Add .customer |
| Billing History | ss.billing.history | ss.customer.billing.history | Add .customer |
| Customer Profile | ss.customer.profile | ss.customer.profile | No change |
| Support Contract | ss.supportcontract | ss.customer.supportcontract | Add .customer |
| 组件 | 当前命名空间 | 目标命名空间 | 操作 |
|---|---|---|---|
| Billing Payment | ss.billing.payment | ss.customer.billing.payment | 添加.customer |
| Billing History | ss.billing.history | ss.customer.billing.history | 添加.customer |
| Customer Profile | ss.customer.profile | ss.customer.profile | 无变更 |
| Support Contract | ss.supportcontract | ss.customer.supportcontract | 添加.customer |
Ticketing Domain Alignment
工单领域对齐
| Component | Current Namespace | Target Namespace | Action |
|---|---|---|---|
| KB Maintenance | ss.kb.maintenance | ss.ticket.kb.maintenance | Add .ticket |
| KB Search | ss.kb.search | ss.ticket.kb.search | Add .ticket |
| Survey | ss.survey | ss.ticket.survey | Add .ticket |
undefined| 组件 | 当前命名空间 | 目标命名空间 | 操作 |
|---|---|---|---|
| KB Maintenance | ss.kb.maintenance | ss.ticket.kb.maintenance | 添加.ticket |
| KB Search | ss.kb.search | ss.ticket.kb.search | 添加.ticket |
| Survey | ss.survey | ss.ticket.survey | 添加.ticket |
undefinedPhase 5: Create Domain Map
阶段5:创建领域映射
Visualize domain structure and component groupings:
-
Create Domain Diagram
- Show domains as boxes
- Show components within each domain
- Show relationships between domains
-
Document Domain Structure
- List domains and their components
- Describe domain responsibilities
- Note domain boundaries
-
Create Domain Inventory
- Table of domains and components
- Component counts per domain
- Size metrics per domain
Example Domain Map:
markdown
undefined可视化领域结构与组件分组:
-
创建领域图
- 将领域显示为方框
- 显示每个领域内的组件
- 显示领域之间的关系
-
记录领域结构
- 列出领域及其组件
- 描述领域职责
- 标注领域边界
-
创建领域清单
- 领域与组件的表格
- 每个领域的组件数量
- 每个领域的规模指标
领域映射示例:
markdown
undefinedDomain Map
领域映射
┌─────────────────────────────────────┐
│ Ticketing Domain (ss.ticket) │
├─────────────────────────────────────┤
│ • Ticket Shared │
│ • Ticket Maintenance │
│ • Ticket Completion │
│ • Ticket Assign │
│ • Ticket Route │
│ • KB Maintenance │
│ • KB Search │
│ • Survey │
└─────────────────────────────────────┘
│
│ uses
▼
┌─────────────────────────────────────┐
│ Customer Domain (ss.customer) │
├─────────────────────────────────────┤
│ • Customer Profile │
│ • Billing Payment │
│ • Billing History │
│ • Support Contract │
└─────────────────────────────────────┘
┌─────────────────────────────────────┐
│ 工单领域 (ss.ticket) │
├─────────────────────────────────────┤
│ • Ticket Shared │
│ • Ticket Maintenance │
│ • Ticket Completion │
│ • Ticket Assign │
│ • Ticket Route │
│ • KB Maintenance │
│ • KB Search │
│ • Survey │
└─────────────────────────────────────┘
│
│ 依赖
▼
┌─────────────────────────────────────┐
│ 客户领域 (ss.customer) │
├─────────────────────────────────────┤
│ • Customer Profile │
│ • Billing Payment │
│ • Billing History │
│ • Support Contract │
└─────────────────────────────────────┘
Output Format
输出格式
Domain Identification Report
领域识别报告
markdown
undefinedmarkdown
undefinedDomain Identification
领域识别
Domain: Customer (ss.customer)
领域:客户 (ss.customer)
Business Capability: Manages customer relationships, billing, and support contracts
Components:
- Customer Profile (ss.customer.profile)
- Billing Payment (ss.customer.billing.payment)
- Billing History (ss.customer.billing.history)
- Support Contract (ss.customer.supportcontract)
Component Count: 4
Total Size: ~15,000 statements (18% of codebase)
Domain Cohesion: ✅ High
- Components share customer-related vocabulary
- Components frequently used together
- Direct relationships between components
Boundaries:
- Clear separation from Ticketing domain
- Clear separation from Reporting domain
- Shared components (Notification) used by all domains
undefined业务能力:管理客户关系、计费与支持合同
组件:
- Customer Profile (ss.customer.profile)
- Billing Payment (ss.customer.billing.payment)
- Billing History (ss.customer.billing.history)
- Support Contract (ss.customer.supportcontract)
组件数量:4
总规模:约15,000行代码(占代码库的18%)
领域内聚性:✅ 高
- 组件共享客户相关词汇
- 组件经常一起使用
- 组件之间有直接关系
边界:
- 与工单领域清晰分离
- 与报表领域清晰分离
- 所有领域使用共享组件(通知)
undefinedComponent Domain Assignment Table
组件-领域分配表
markdown
undefinedmarkdown
undefinedComponent Domain Assignment
组件-领域分配
| Component | Current Namespace | Assigned Domain | Target Namespace |
|---|---|---|---|
| Customer Profile | ss.customer.profile | Customer | ss.customer.profile (no change) |
| Billing Payment | ss.billing.payment | Customer | ss.customer.billing.payment |
| Ticket Maintenance | ss.ticket.maintenance | Ticketing | ss.ticket.maintenance (no change) |
| KB Maintenance | ss.kb.maintenance | Ticketing | ss.ticket.kb.maintenance |
| Reporting Shared | ss.reporting.shared | Reporting | ss.reporting.shared (no change) |
undefined| 组件 | 当前命名空间 | 分配领域 | 目标命名空间 |
|---|---|---|---|
| Customer Profile | ss.customer.profile | 客户 | ss.customer.profile (无变更) |
| Billing Payment | ss.billing.payment | 客户 | ss.customer.billing.payment |
| Ticket Maintenance | ss.ticket.maintenance | 工单 | ss.ticket.maintenance (无变更) |
| KB Maintenance | ss.kb.maintenance | 工单 | ss.ticket.kb.maintenance |
| Reporting Shared | ss.reporting.shared | 报表 | ss.reporting.shared (无变更) |
undefinedNamespace Refactoring Plan
命名空间重构计划
markdown
undefinedmarkdown
undefinedNamespace Refactoring Plan
命名空间重构计划
Priority: High
优先级:高
Customer Domain Alignment
Components to Refactor:
- Billing Payment: →
ss.billing.paymentss.customer.billing.payment - Billing History: →
ss.billing.historyss.customer.billing.history - Support Contract: →
ss.supportcontractss.customer.supportcontract
Steps:
- Update namespace declarations in source files
- Update import statements in dependent components
- Update directory structure
- Run tests to verify changes
- Update documentation
Expected Impact:
- All customer-related components aligned under domain
.customer - Clearer domain boundaries
- Easier to identify domain components
undefined客户领域对齐
需要重构的组件:
- Billing Payment: →
ss.billing.paymentss.customer.billing.payment - Billing History: →
ss.billing.historyss.customer.billing.history - Support Contract: →
ss.supportcontractss.customer.supportcontract
步骤:
- 更新源文件中的命名空间声明
- 更新依赖组件中的导入语句
- 更新目录结构
- 运行测试验证变更
- 更新文档
预期影响:
- 所有客户相关组件对齐到领域下
.customer - 领域边界更清晰
- 更容易识别领域组件
undefinedDomain Map Visualization
领域映射可视化
markdown
undefinedmarkdown
undefinedDomain Map
领域映射
Domain Structure
领域结构
Customer Domain (ss.customer)
├── Customer Profile
├── Billing Payment
├── Billing History
└── Support Contract
Ticketing Domain (ss.ticket)
├── Ticket Shared
├── Ticket Maintenance
├── Ticket Completion
├── Ticket Assign
├── Ticket Route
├── KB Maintenance
├── KB Search
└── Survey
Reporting Domain (ss.reporting)
├── Reporting Shared
├── Ticket Reports
├── Expert Reports
└── Financial Reports
Admin Domain (ss.admin)
├── User Maintenance
└── Expert Profile
Shared Domain (ss.shared)
├── Login
└── Notification
客户领域 (ss.customer)
├── Customer Profile
├── Billing Payment
├── Billing History
└── Support Contract
工单领域 (ss.ticket)
├── Ticket Shared
├── Ticket Maintenance
├── Ticket Completion
├── Ticket Assign
├── Ticket Route
├── KB Maintenance
├── KB Search
└── Survey
报表领域 (ss.reporting)
├── Reporting Shared
├── Ticket Reports
├── Expert Reports
└── Financial Reports
管理领域 (ss.admin)
├── User Maintenance
└── Expert Profile
共享领域 (ss.shared)
├── Login
└── Notification
Domain Relationships
领域关系
Ticketing Domain
│ uses
├─→ Shared Domain (Login, Notification)
└─→ Customer Domain (Customer Profile)
Customer Domain
│ uses
└─→ Shared Domain (Login, Notification)
Reporting Domain
│ uses
├─→ Ticketing Domain (Ticket data)
├─→ Customer Domain (Customer data)
└─→ Shared Domain (Login)
undefined
工单领域
│ 依赖
├─→ 共享领域 (登录、通知)
└─→ 客户领域 (客户档案)
客户领域
│ 依赖
└─→ 共享领域 (登录、通知)
报表领域
│ 依赖
├─→ 工单领域 (工单数据)
├─→ 客户领域 (客户数据)
└─→ 共享领域 (登录)
undefinedAnalysis Checklist
分析清单
Domain Identification:
- Analyzed component responsibilities
- Identified business capabilities
- Identified distinct business domains
- Validated domains with stakeholders
Component Grouping:
- Assigned each component to a domain
- Analyzed component relationships
- Ensured components fit domain vocabulary
- Handled edge cases (shared components, unclear assignments)
Domain Validation:
- Checked cohesion within domains
- Verified domain boundaries are clear
- Ensured all components assigned
- Validated with stakeholders
Namespace Refactoring:
- Compared current vs target namespaces
- Identified components needing refactoring
- Created refactoring plan
- Prioritized refactoring work
Domain Mapping:
- Created domain diagram
- Documented domain structure
- Created domain inventory table
- Documented domain relationships
领域识别:
- 分析了组件职责
- 识别了业务能力
- 识别了独立的业务领域
- 与利益相关者验证了领域
组件分组:
- 每个组件已分配到领域
- 分析了组件关系
- 确保组件符合领域词汇
- 处理了边缘情况(共享组件、不明确的分配)
领域验证:
- 检查了领域内聚性
- 验证了领域边界清晰
- 确保所有组件已分配
- 与利益相关者验证
命名空间重构:
- 对比了当前与目标命名空间
- 识别了需要重构的组件
- 创建了重构计划
- 确定了重构工作的优先级
领域映射:
- 创建了领域图
- 记录了领域结构
- 创建了领域清单表
- 记录了领域关系
Implementation Notes
实现说明
For Node.js/Express Applications
适用于Node.js/Express应用
Domains typically organized in directory:
services/services/
├── customer/ ← Customer Domain
│ ├── profile/
│ ├── billing/
│ │ ├── payment/
│ │ └── history/
│ └── supportcontract/
├── ticket/ ← Ticketing Domain
│ ├── shared/
│ ├── maintenance/
│ ├── assign/
│ └── route/
└── reporting/ ← Reporting Domain
├── shared/
├── tickets/
└── experts/领域通常在目录下组织:
services/services/
├── customer/ ← 客户领域
│ ├── profile/
│ ├── billing/
│ │ ├── payment/
│ │ └── history/
│ └── supportcontract/
├── ticket/ ← 工单领域
│ ├── shared/
│ ├── maintenance/
│ ├── assign/
│ └── route/
└── reporting/ ← 报表领域
├── shared/
├── tickets/
└── experts/For Java Applications
适用于Java应用
Domains identified by package structure:
com.company.customer ← Customer Domain
├── profile
├── billing
│ ├── payment
│ └── history
└── supportcontract
com.company.ticket ← Ticketing Domain
├── shared
├── maintenance
├── assign
└── route领域通过包结构识别:
com.company.customer ← 客户领域
├── profile
├── billing
│ ├── payment
│ └── history
└── supportcontract
com.company.ticket ← 工单领域
├── shared
├── maintenance
├── assign
└── routeDomain Identification Strategies
领域识别策略
Strategy 1: Business Capability Analysis
- Identify what business capabilities the system provides
- Group components by capability
- Example: "Customer Management" capability → Customer Domain
Strategy 2: Vocabulary Analysis
- Identify business vocabulary used by components
- Group components sharing same vocabulary
- Example: Components using "billing", "payment", "invoice" → Financial Domain
Strategy 3: Relationship Analysis
- Identify components frequently used together
- Group components with strong relationships
- Example: Components that share data/workflows → Same Domain
Strategy 4: Stakeholder Collaboration
- Work with product owners/business analysts
- Use their understanding of business areas
- Validate domain boundaries with them
策略1:业务能力分析
- 识别系统提供的业务能力
- 按能力对组件分组
- 示例:"客户管理"能力 → 客户领域
策略2:词汇分析
- 识别组件使用的业务词汇
- 按共享词汇对组件分组
- 示例:使用"billing"、"payment"、"invoice"的组件 → 财务领域
策略3:关系分析
- 识别经常一起使用的组件
- 对关系紧密的组件分组
- 示例:共享数据/工作流的组件 → 同一领域
策略4:利益相关者协作
- 与产品负责人/业务分析师合作
- 利用他们对业务领域的认知
- 与他们验证领域边界
Fitness Functions
适配函数
After creating domains, create automated checks:
创建领域后,创建自动化检查:
Domain Namespace Governance
领域命名空间治理
javascript
// Ensure components belong to correct domain
function validateDomainNamespaces(components, domainRules) {
const violations = []
components.forEach((comp) => {
const domain = identifyDomain(comp.namespace)
const expectedDomain = domainRules[comp.name]
if (domain !== expectedDomain) {
violations.push({
component: comp.name,
currentDomain: domain,
expectedDomain: expectedDomain,
namespace: comp.namespace,
})
}
})
return violations
}javascript
// Ensure components belong to correct domain
function validateDomainNamespaces(components, domainRules) {
const violations = []
components.forEach((comp) => {
const domain = identifyDomain(comp.namespace)
const expectedDomain = domainRules[comp.name]
if (domain !== expectedDomain) {
violations.push({
component: comp.name,
currentDomain: domain,
expectedDomain: expectedDomain,
namespace: comp.namespace,
})
}
})
return violations
}Domain Boundary Enforcement
领域边界强制执行
javascript
// Prevent components from accessing other domains directly
function enforceDomainBoundaries(components) {
const violations = []
components.forEach((comp) => {
comp.imports.forEach((imp) => {
const importedDomain = identifyDomain(imp)
const componentDomain = identifyDomain(comp.namespace)
if (importedDomain !== componentDomain && importedDomain !== 'shared') {
violations.push({
component: comp.name,
domain: componentDomain,
importsFrom: imp,
importedDomain: importedDomain,
issue: 'Cross-domain direct dependency',
})
}
})
})
return violations
}javascript
// Prevent components from accessing other domains directly
function enforceDomainBoundaries(components) {
const violations = []
components.forEach((comp) => {
comp.imports.forEach((imp) => {
const importedDomain = identifyDomain(imp)
const componentDomain = identifyDomain(comp.namespace)
if (importedDomain !== componentDomain && importedDomain !== 'shared') {
violations.push({
component: comp.name,
domain: componentDomain,
importsFrom: imp,
importedDomain: importedDomain,
issue: 'Cross-domain direct dependency',
})
}
})
})
return violations
}Best Practices
最佳实践
Do's ✅
建议✅
- Collaborate with business stakeholders to identify domains
- Group components by business capability, not technical layers
- Ensure domains represent distinct business areas
- Validate domain boundaries with stakeholders
- Refactor namespaces to align with domains
- Create clear domain documentation
- Use business language in domain names
- 与业务利益相关者协作识别领域
- 按业务能力而非技术层分组组件
- 确保领域代表独立的业务领域
- 与利益相关者验证领域边界
- 重构命名空间以对齐领域
- 创建清晰的领域文档
- 在领域名称中使用业务语言
Don'ts ❌
不建议❌
- Don't create domains based on technical layers (services, controllers, models)
- Don't force components into domains where they don't fit
- Don't skip stakeholder validation
- Don't create too many small domains (aim for 3-7 domains)
- Don't create domains that are too large (monolithic domains)
- Don't ignore components that don't fit (analyze why)
- Don't skip namespace refactoring (critical for clarity)
- 不要基于技术层(服务、控制器、模型)创建领域
- 不要强行将组件归入不匹配的领域
- 不要跳过利益相关者验证
- 不要创建过多小领域(目标3-7个领域)
- 不要创建过大的领域(单体领域)
- 不要忽略无法归类的组件(分析原因)
- 不要跳过命名空间重构(对清晰度至关重要)
Common Domain Patterns
常见领域模式
Typical Domains in Business Applications
业务应用中的典型领域
- Customer Domain: Customer management, profiles, relationships
- Product Domain: Product catalog, inventory, pricing
- Order Domain: Order processing, fulfillment, shipping
- Billing Domain: Invoicing, payments, financial transactions
- Reporting Domain: Reports, analytics, dashboards
- Admin Domain: User management, system configuration
- Shared Domain: Common functionality (login, notification, utilities)
- 客户领域:客户管理、档案、关系
- 产品领域:产品目录、库存、定价
- 订单领域:订单处理、履行、配送
- 计费领域:发票、支付、财务交易
- 报表领域:报表、分析、仪表板
- 管理领域:用户管理、系统配置
- 共享领域:通用功能(登录、通知、工具)
Domain Size Guidelines
领域规模指南
- Small Domain: 2-4 components
- Medium Domain: 5-8 components
- Large Domain: 9-15 components
- Too Large: >15 components (consider splitting)
- 小型领域:2-4个组件
- 中型领域:5-8个组件
- 大型领域:9-15个组件
- 过大:>15个组件(考虑拆分)
Next Steps
后续步骤
After creating component domains:
- Apply Create Domain Services Pattern - Extract domains to separate services
- Plan Service Extraction - Create migration plan for domain services
- Implement Domain Services - Move domains to separately deployed services
- Monitor Domain Boundaries - Use fitness functions to enforce boundaries
创建组件领域后:
- 应用创建领域服务模式 - 将领域提取为独立服务
- 规划服务提取 - 创建领域服务的迁移计划
- 实现领域服务 - 将领域迁移到独立部署的服务
- 监控领域边界 - 使用适配函数强制执行边界
Notes
注意事项
- Domains should represent business capabilities, not technical layers
- Domain identification requires collaboration with business stakeholders
- Namespace refactoring is critical for domain clarity
- Domains prepare the codebase for service-based architecture
- Well-formed domains make service extraction easier
- Domain boundaries should be clear and well-documented
- 领域应代表业务能力,而非技术层
- 领域识别需要与业务利益相关者协作
- 命名空间重构对领域清晰度至关重要
- 领域为代码库适配service-based architecture做准备
- 结构良好的领域使服务提取更容易
- 领域边界应清晰且有完善的文档