domain-identification-grouping

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Domain 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 alignment
Example 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 assignment
Example 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

分步流程

  1. Identify Domains: Analyze business capabilities and component relationships
  2. Group Components: Assign components to appropriate domains
  3. Validate Groupings: Ensure components fit well in their domains
  4. Refactor Namespaces: Align component namespaces with domains
  5. Create Domain Map: Visualize domain structure and component groupings
  1. 识别领域:分析业务能力与组件关系
  2. 分组组件:将组件分配到合适的领域
  3. 验证分组:确保组件与所属领域匹配度良好
  4. 重构命名空间:调整组件命名空间以匹配领域
  5. 创建领域映射:可视化领域结构与组件分组

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/supportcontract
After Domain Alignment:
services/customer/billing/payment
services/customer/billing/history
services/customer/profile
services/customer/supportcontract
Notice how all customer-related functionality is grouped under
.customer
domain.
领域通过命名空间结构物理体现:
领域对齐前
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
注意所有客户相关功能如何归到
.customer
领域下。

Analysis Process

分析流程

Phase 1: Identify Business Domains

阶段1:识别业务领域

Analyze the codebase to identify distinct business domains:
  1. Examine Component Responsibilities
    • Read component names and descriptions
    • Understand what each component does
    • Identify business capabilities
  2. Look for Business Language
    • Group components by business vocabulary
    • Example: "billing", "payment", "invoice" → Financial domain
    • Example: "customer", "profile", "contract" → Customer domain
  3. Identify Domain Boundaries
    • Where do business concepts change?
    • What are the distinct business areas?
    • How do components relate to business capabilities?
  4. 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
分析代码库以识别独立的业务领域:
  1. 检查组件职责
    • 阅读组件名称与描述
    • 理解每个组件的功能
    • 识别业务能力
  2. 寻找业务语言
    • 按业务词汇对组件分组
    • 示例:"billing"、"payment"、"invoice" → 财务领域
    • 示例:"customer"、"profile"、"contract" → 客户领域
  3. 识别领域边界
    • 业务概念的分界点在哪里?
    • 有哪些独立的业务领域?
    • 组件如何与业务能力关联?
  4. 与业务利益相关者协作
    • 与产品负责人验证领域识别结果
    • 确保领域与业务认知对齐
    • 获取关于领域边界的反馈
领域识别示例
markdown
undefined

Identified Domains

已识别领域

  1. Ticketing Domain (ss.ticket)
    • Ticket creation, assignment, routing, completion
    • Customer surveys
    • Knowledge base
  2. Customer Domain (ss.customer)
    • Customer profile
    • Billing and payment
    • Support contracts
  3. Reporting Domain (ss.reporting)
    • Ticket reports
    • Expert reports
    • Financial reports
  4. Admin Domain (ss.admin)
    • User maintenance
    • Expert profile management
  5. Shared Domain (ss.shared)
    • Login
    • Notification
undefined
  1. 工单领域 (ss.ticket)
    • 工单创建、分配、路由、完成
    • 客户调查
    • 知识库
  2. 客户领域 (ss.customer)
    • 客户档案
    • 计费与支付
    • 支持合同
  3. 报表领域 (ss.reporting)
    • 工单报表
    • 专家报表
    • 财务报表
  4. 管理领域 (ss.admin)
    • 用户维护
    • 专家档案管理
  5. 共享领域 (ss.shared)
    • 登录
    • 通知
undefined

Phase 2: Group Components into Domains

阶段2:将组件分组到领域

Assign each component to an appropriate domain:
  1. Analyze Component Functionality
    • What business capability does it support?
    • What domain vocabulary does it use?
    • What other components does it relate to?
  2. Check Component Relationships
    • Which components are frequently used together?
    • What are the dependencies between components?
    • Do components share data or workflows?
  3. 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
  4. 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
将每个组件分配到合适的领域:
  1. 分析组件功能
    • 它支持哪些业务能力?
    • 使用了哪些领域词汇?
    • 与其他组件有哪些关联?
  2. 检查组件关系
    • 哪些组件经常一起使用?
    • 组件之间有哪些依赖?
    • 组件是否共享数据或工作流?
  3. 分配到领域
    • 将组件放置到最符合其功能的领域
    • 确保组件与领域的业务语言对齐
    • 验证组件关系支持领域分组
  4. 处理边缘情况
    • 无法明确归类的组件:深入分析
    • 适合多个领域的组件:选择主领域
    • 共享组件:可归到共享领域
组件分组示例
markdown
undefined

Component 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)
undefined

Phase 3: Validate Domain Groupings

阶段3:验证领域分组

Ensure components fit well in their assigned domains:
  1. Check Cohesion
    • Do components in domain share business language?
    • Are components frequently used together?
    • Do components have direct relationships?
  2. Verify Boundaries
    • Are domain boundaries clear?
    • Do components belong to only one domain?
    • Are there components that don't fit anywhere?
  3. Assess Completeness
    • Are all components assigned to a domain?
    • Are domains cohesive and well-formed?
    • Do domains represent distinct business capabilities?
  4. 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
确保组件与分配的领域匹配度良好:
  1. 检查内聚性
    • 领域内的组件是否共享业务语言?
    • 组件是否经常一起使用?
    • 组件之间是否有直接关系?
  2. 验证边界
    • 领域边界是否清晰?
    • 组件是否仅属于一个领域?
    • 是否有组件无法归类?
  3. 评估完整性
    • 所有组件是否都已分配到领域?
    • 领域是否内聚且结构合理?
    • 领域是否代表独立的业务能力?
  4. 获取利益相关者验证
    • 与产品负责人审核领域分组
    • 确保领域与业务认知对齐
    • 获取关于领域边界的反馈
验证清单
  • 所有组件已分配到领域
  • 领域边界清晰
  • 组件与所属领域匹配度良好
  • 领域代表独立的业务能力
  • 利益相关者已验证领域分组

Phase 4: Refactor Namespaces for Domain Alignment

阶段4:重构命名空间以实现领域对齐

Align component namespaces with identified domains:
  1. Compare Current vs Target Namespaces
    • Current:
      services/billing/payment
    • Target:
      services/customer/billing/payment
    • Change: Add
      .customer
      domain node
  2. Identify Refactoring Needed
    • Which components need namespace changes?
    • What domain nodes need to be added?
    • Are there components already aligned?
  3. Create Refactoring Plan
    • List components needing namespace changes
    • Specify target namespace for each
    • Prioritize refactoring work
  4. Execute Refactoring
    • Update component namespaces
    • Update imports/references
    • Verify all references updated
Example Namespace Refactoring:
markdown
undefined
调整组件命名空间以匹配已识别的领域:
  1. 对比当前与目标命名空间
    • 当前:
      services/billing/payment
    • 目标:
      services/customer/billing/payment
    • 变更:添加
      .customer
      领域节点
  2. 识别需要重构的内容
    • 哪些组件需要变更命名空间?
    • 需要添加哪些领域节点?
    • 哪些组件已对齐?
  3. 创建重构计划
    • 列出需要变更命名空间的组件
    • 指定每个组件的目标命名空间
    • 确定重构工作的优先级
  4. 执行重构
    • 更新组件命名空间
    • 更新导入/引用
    • 验证所有引用已更新
命名空间重构示例
markdown
undefined

Namespace Refactoring Plan

命名空间重构计划

Customer Domain Alignment

客户领域对齐

ComponentCurrent NamespaceTarget NamespaceAction
Billing Paymentss.billing.paymentss.customer.billing.paymentAdd .customer
Billing Historyss.billing.historyss.customer.billing.historyAdd .customer
Customer Profiless.customer.profiless.customer.profileNo change
Support Contractss.supportcontractss.customer.supportcontractAdd .customer
组件当前命名空间目标命名空间操作
Billing Paymentss.billing.paymentss.customer.billing.payment添加.customer
Billing Historyss.billing.historyss.customer.billing.history添加.customer
Customer Profiless.customer.profiless.customer.profile无变更
Support Contractss.supportcontractss.customer.supportcontract添加.customer

Ticketing Domain Alignment

工单领域对齐

ComponentCurrent NamespaceTarget NamespaceAction
KB Maintenancess.kb.maintenancess.ticket.kb.maintenanceAdd .ticket
KB Searchss.kb.searchss.ticket.kb.searchAdd .ticket
Surveyss.surveyss.ticket.surveyAdd .ticket
undefined
组件当前命名空间目标命名空间操作
KB Maintenancess.kb.maintenancess.ticket.kb.maintenance添加.ticket
KB Searchss.kb.searchss.ticket.kb.search添加.ticket
Surveyss.surveyss.ticket.survey添加.ticket
undefined

Phase 5: Create Domain Map

阶段5:创建领域映射

Visualize domain structure and component groupings:
  1. Create Domain Diagram
    • Show domains as boxes
    • Show components within each domain
    • Show relationships between domains
  2. Document Domain Structure
    • List domains and their components
    • Describe domain responsibilities
    • Note domain boundaries
  3. Create Domain Inventory
    • Table of domains and components
    • Component counts per domain
    • Size metrics per domain
Example Domain Map:
markdown
undefined
可视化领域结构与组件分组:
  1. 创建领域图
    • 将领域显示为方框
    • 显示每个领域内的组件
    • 显示领域之间的关系
  2. 记录领域结构
    • 列出领域及其组件
    • 描述领域职责
    • 标注领域边界
  3. 创建领域清单
    • 领域与组件的表格
    • 每个领域的组件数量
    • 每个领域的规模指标
领域映射示例
markdown
undefined

Domain 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
undefined
markdown
undefined

Domain 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%)
领域内聚性:✅ 高
  • 组件共享客户相关词汇
  • 组件经常一起使用
  • 组件之间有直接关系
边界
  • 与工单领域清晰分离
  • 与报表领域清晰分离
  • 所有领域使用共享组件(通知)
undefined

Component Domain Assignment Table

组件-领域分配表

markdown
undefined
markdown
undefined

Component Domain Assignment

组件-领域分配

ComponentCurrent NamespaceAssigned DomainTarget Namespace
Customer Profiless.customer.profileCustomerss.customer.profile (no change)
Billing Paymentss.billing.paymentCustomerss.customer.billing.payment
Ticket Maintenancess.ticket.maintenanceTicketingss.ticket.maintenance (no change)
KB Maintenancess.kb.maintenanceTicketingss.ticket.kb.maintenance
Reporting Sharedss.reporting.sharedReportingss.reporting.shared (no change)
undefined
组件当前命名空间分配领域目标命名空间
Customer Profiless.customer.profile客户ss.customer.profile (无变更)
Billing Paymentss.billing.payment客户ss.customer.billing.payment
Ticket Maintenancess.ticket.maintenance工单ss.ticket.maintenance (无变更)
KB Maintenancess.kb.maintenance工单ss.ticket.kb.maintenance
Reporting Sharedss.reporting.shared报表ss.reporting.shared (无变更)
undefined

Namespace Refactoring Plan

命名空间重构计划

markdown
undefined
markdown
undefined

Namespace Refactoring Plan

命名空间重构计划

Priority: High

优先级:高

Customer Domain Alignment
Components to Refactor:
  1. Billing Payment:
    ss.billing.payment
    ss.customer.billing.payment
  2. Billing History:
    ss.billing.history
    ss.customer.billing.history
  3. Support Contract:
    ss.supportcontract
    ss.customer.supportcontract
Steps:
  1. Update namespace declarations in source files
  2. Update import statements in dependent components
  3. Update directory structure
  4. Run tests to verify changes
  5. Update documentation
Expected Impact:
  • All customer-related components aligned under
    .customer
    domain
  • Clearer domain boundaries
  • Easier to identify domain components
undefined
客户领域对齐
需要重构的组件
  1. Billing Payment:
    ss.billing.payment
    ss.customer.billing.payment
  2. Billing History:
    ss.billing.history
    ss.customer.billing.history
  3. Support Contract:
    ss.supportcontract
    ss.customer.supportcontract
步骤
  1. 更新源文件中的命名空间声明
  2. 更新依赖组件中的导入语句
  3. 更新目录结构
  4. 运行测试验证变更
  5. 更新文档
预期影响
  • 所有客户相关组件对齐到
    .customer
    领域下
  • 领域边界更清晰
  • 更容易识别领域组件
undefined

Domain Map Visualization

领域映射可视化

markdown
undefined
markdown
undefined

Domain 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

工单领域
│ 依赖
├─→ 共享领域 (登录、通知)
└─→ 客户领域 (客户档案)

客户领域
│ 依赖
└─→ 共享领域 (登录、通知)

报表领域
│ 依赖
├─→ 工单领域 (工单数据)
├─→ 客户领域 (客户数据)
└─→ 共享领域 (登录)
undefined

Analysis 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
services/
directory:
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
└── route

Domain 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:
  1. Apply Create Domain Services Pattern - Extract domains to separate services
  2. Plan Service Extraction - Create migration plan for domain services
  3. Implement Domain Services - Move domains to separately deployed services
  4. Monitor Domain Boundaries - Use fitness functions to enforce boundaries
创建组件领域后:
  1. 应用创建领域服务模式 - 将领域提取为独立服务
  2. 规划服务提取 - 创建领域服务的迁移计划
  3. 实现领域服务 - 将领域迁移到独立部署的服务
  4. 监控领域边界 - 使用适配函数强制执行边界

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做准备
  • 结构良好的领域使服务提取更容易
  • 领域边界应清晰且有完善的文档