Domain Analysis

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.

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 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

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)

Analysis Process

Phase 1: Extract Concepts

Scan codebase for business concepts (not infrastructure):

1. Entities (domain models with identity)

• Patterns: @Entity, class, domain models
• Focus: Business concepts, not technical classes

2. Services (business operations)

• Patterns: *Service, *Manager, *Handler
• Focus: Business logic, not technical utilities

3. Use Cases (business workflows)

• Patterns: *UseCase, *Command, *Handler
• Focus: Business processes, not CRUD

4. Controllers/Resolvers (entry points)

• Patterns: *Controller, *Resolver, API endpoints
• Focus: Business capabilities, not technical routes

Phase 2: Group by Ubiquitous Language

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?

Phase 3: Identify Subdomains

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

Phase 4: Assess Cohesion

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 ❌

Phase 5: Detect Low Cohesion Issues

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

Phase 6: Map Bounded Contexts

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

Output Format

Domain Map

For each domain/subdomain:

## 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

Cohesion Matrix

## 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 |

Low Cohesion Report

## 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}

Bounded Context Map

## 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

Best Practices

Do's ✅

• Focus on business language, not code structure
• Let Ubiquitous Language guide boundaries
• Measure cohesion objectively
• Identify clear integration points
• Classify every subdomain (Core/Supporting/Generic)
• Look for linguistic boundaries first

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

For Each Concept:

• [ ] What business language does it belong to?
• [ ] What domain/subdomain is it part of?
• [ ] Is it Core, Supporting, or Generic?
• [ ] What other concepts does it relate to?
• [ ] Are dependencies within same domain?
• [ ] Any linguistic mismatches?

For Each Domain:

• [ ] What is the Ubiquitous Language?
• [ ] What are the key concepts?
• [ ] What are the subdomains?
• [ ] Which is the Core Domain?
• [ ] What are cross-domain dependencies?
• [ ] Is internal cohesion high?
• [ ] Are boundaries clear?

For Cohesion Analysis:

• [ ] Calculate cohesion scores
• [ ] Identify low cohesion areas
• [ ] Map cross-domain dependencies
• [ ] Flag linguistic mismatches
• [ ] Note tight coupling
• [ ] Suggest boundary clarifications

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

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

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

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

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

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

Subdomain Identification Examples

This document provides practical examples of applying subdomain identification across different types of codebases.

Example 1: E-Commerce Platform

Discovered Concepts

Entities:

• Product, Category, Inventory, SKU
• Order, OrderItem, Cart, CartItem
• Customer, Address, PaymentMethod
• Shipment, Tracking, Warehouse

Services:

• ProductCatalogService, InventoryService
• OrderProcessingService, CartService
• PaymentService, ShippingService
• CustomerService

Language Groups

Catalog Language: product, category, SKU, inventory, stock Order Language: order, cart, checkout, fulfillment Payment Language: payment, transaction, refund, charge Shipping Language: shipment, tracking, delivery, carrier Customer Language: customer, account, profile, address

Identified Subdomains

1. Product Catalog (Core Domain)

• Type: Core (if differentiation is product discovery)
• Ubiquitous Language: product, category, catalog, search, browse
• Concepts: Product, Category, ProductCatalogService
• Cohesion: 9/10
• Bounded Context: CatalogContext

2. Inventory Management (Supporting)

• Type: Supporting
• Ubiquitous Language: stock, inventory, SKU, warehouse, allocation
• Concepts: Inventory, SKU, InventoryService, Warehouse
• Cohesion: 8/10
• Bounded Context: InventoryContext

3. Order Processing (Core Domain)

• Type: Core (if differentiation is checkout experience)
• Ubiquitous Language: order, cart, checkout, fulfillment
• Concepts: Order, Cart, OrderProcessingService
• Cohesion: 9/10
• Bounded Context: OrderContext

4. Payment Processing (Generic)

• Type: Generic (standard payment gateway)
• Ubiquitous Language: payment, transaction, charge, refund
• Concepts: Payment, PaymentService, PaymentGateway
• Cohesion: 7/10
• Bounded Context: PaymentContext

5. Shipping (Supporting)

• Type: Supporting
• Ubiquitous Language: shipment, tracking, delivery, carrier
• Concepts: Shipment, Tracking, ShippingService
• Cohesion: 8/10
• Bounded Context: ShippingContext

Cohesion Analysis

Low Cohesion Issues

Issue 1: Customer entity directly referenced in Order

• Problem: Different contexts (Identity vs Order)
• Recommendation: Use CustomerId value object, not entity reference
• Pattern: Published Language

Issue 2: Catalog service checks Inventory directly

• Problem: Core Domain depends on Supporting
• Recommendation: Use event-based inventory updates
• Pattern: Domain Events

---

Example 2: Healthcare System

Discovered Concepts

Entities:

• Patient, MedicalRecord, Diagnosis
• Appointment, Schedule, Availability
• Prescription, Medication, Dosage
• Doctor, Nurse, Staff
• Billing, Claim, Insurance

Language Groups

Clinical Language: patient, diagnosis, treatment, medical record Scheduling Language: appointment, schedule, availability, slot Pharmacy Language: prescription, medication, dosage, drug Staff Language: doctor, nurse, practitioner, credential Billing Language: claim, insurance, copay, reimbursement

Identified Subdomains

1. Patient Care (Core Domain)

• Type: Core
• Ubiquitous Language: patient, diagnosis, treatment, care plan
• Concepts: Patient, MedicalRecord, Diagnosis, CareService
• Cohesion: 9/10
• Bounded Context: ClinicalContext

2. Appointment Management (Supporting)

• Type: Supporting
• Ubiquitous Language: appointment, schedule, availability, booking
• Concepts: Appointment, Schedule, SchedulingService
• Cohesion: 8/10
• Bounded Context: SchedulingContext

3. Pharmacy (Supporting)

• Type: Supporting (or Core if pharmacy is differentiator)
• Ubiquitous Language: prescription, medication, dosage, drug interaction
• Concepts: Prescription, Medication, PharmacyService
• Cohesion: 8/10
• Bounded Context: PharmacyContext

4. Medical Billing (Supporting)

• Type: Supporting
• Ubiquitous Language: claim, insurance, billing, reimbursement
• Concepts: Claim, Insurance, BillingService
• Cohesion: 7/10
• Bounded Context: BillingContext

Key Insight

"Patient" Concept Has Different Meanings:

→ These are different bounded contexts despite sharing the term "Patient"

---

Example 3: SaaS Project Management Tool

Discovered Concepts

Entities:

• Project, Task, Milestone, Sprint
• User, Team, Role, Permission
• Comment, Attachment, Activity
• Subscription, Plan, Invoice
• Notification, Alert

Language Groups

Project Language: project, task, milestone, sprint, backlog Collaboration Language: comment, discussion, mention, activity Access Language: user, team, role, permission, access Billing Language: subscription, plan, invoice, payment Notification Language: notification, alert, reminder

Identified Subdomains

1. Project Management (Core Domain)

• Type: Core
• Ubiquitous Language: project, task, milestone, workflow
• Concepts: Project, Task, Milestone, ProjectService
• Cohesion: 9/10
• Bounded Context: ProjectContext

2. Collaboration (Core/Supporting)

• Type: Core if differentiator, Supporting otherwise
• Ubiquitous Language: comment, discussion, activity, collaboration
• Concepts: Comment, Activity, CollaborationService
• Cohesion: 8/10
• Bounded Context: CollaborationContext

3. Identity & Access (Generic)

• Type: Generic
• Ubiquitous Language: user, authentication, authorization, role
• Concepts: User, Role, Permission, AuthService
• Cohesion: 9/10
• Bounded Context: IdentityContext

4. Billing (Supporting)

• Type: Supporting
• Ubiquitous Language: subscription, plan, invoice, billing
• Concepts: Subscription, Invoice, BillingService
• Cohesion: 8/10
• Bounded Context: BillingContext

5. Notifications (Generic)

• Type: Generic
• Ubiquitous Language: notification, alert, message, reminder
• Concepts: Notification, NotificationService
• Cohesion: 7/10
• Bounded Context: NotificationContext

Low Cohesion Issue

Issue: User entity used everywhere

// Project domain
class Project {
  owner: User;        // ❌ Direct reference
  members: User[];    // ❌ Direct reference
}

// Collaboration domain
class Comment {
  author: User;       // ❌ Direct reference
}

// Billing domain
class Subscription {
  subscriber: User;   // ❌ Direct reference
}

Problem: Identity context concept leaked into all domains

Recommendation: Use context-specific concepts

// Project domain
class Project {
  ownerId: OwnerId;           // ✅ Value object
  members: MemberId[];        // ✅ Value object
}

// Collaboration domain
class Comment {
  authorId: ParticipantId;    // ✅ Context-specific
}

// Billing domain
class Subscription {
  subscriberId: CustomerId;   // ✅ Context-specific
}

---

Example 4: Streaming Video Platform

Discovered Concepts

Entities:

• Movie, TVShow, Episode, Season
• Video, Stream, Encoding, Quality
• Watchlist, Viewing, Progress
• Recommendation, Preference
• Subscription, Plan, Billing

Language Groups

Content Language: movie, show, episode, season, catalog Streaming Language: video, stream, encoding, bitrate, quality Engagement Language: watchlist, viewing, progress, rating Recommendation Language: recommendation, preference, algorithm Billing Language: subscription, plan, billing, payment

Identified Subdomains

1. Content Catalog (Supporting)

• Type: Supporting (unless unique content is differentiator)
• Ubiquitous Language: movie, show, episode, catalog, metadata
• Concepts: Movie, TVShow, Episode, CatalogService
• Cohesion: 9/10
• Bounded Context: CatalogContext

2. Video Streaming (Supporting)

• Type: Supporting
• Ubiquitous Language: video, stream, encoding, playback, quality
• Concepts: Video, Stream, StreamingService
• Cohesion: 8/10
• Bounded Context: StreamingContext

3. User Engagement (Supporting)

• Type: Supporting
• Ubiquitous Language: watchlist, viewing, progress, rating
• Concepts: Watchlist, Viewing, EngagementService
• Cohesion: 8/10
• Bounded Context: EngagementContext

4. Recommendation Engine (Core Domain)

• Type: Core (if algorithm is competitive advantage)
• Ubiquitous Language: recommendation, preference, algorithm, personalization
• Concepts: Recommendation, RecommendationEngine
• Cohesion: 9/10
• Bounded Context: RecommendationContext

5. Video Processing (Generic)

• Type: Generic
• Ubiquitous Language: transcoding, encoding, compression
• Concepts: VideoProcessor, EncodingService
• Cohesion: 7/10
• Bounded Context: ProcessingContext

Integration Pattern

Catalog Context → publishes → ContentPublished event
                              ↓
                   Recommendation Context ← consumes
                              ↓
Engagement Context → publishes → UserWatched event
                              ↓
                   Recommendation Context ← consumes

Pattern: Event-Driven Architecture with Domain Events

---

Common Patterns Across Examples

Pattern 1: Identity Leakage

Problem: User/Identity entities used directly everywhere

Solution: Context-specific identifiers

• Project context: OwnerId, MemberId
• Billing context: CustomerId, SubscriberId
• Content context: CreatorId, ViewerId

Pattern 2: Shared Kernel Overuse

Problem: Large shared models used everywhere

Solution: Minimal shared kernel, mostly value objects

• Share: UserId (as string/UUID), Email (as value object)
• Don't share: User entity, Customer entity

Pattern 3: Core vs Supporting Confusion

Key Question: "Is this our competitive advantage?"

• If YES → Core Domain (best team, most attention)
• If NO but business-specific → Supporting
• If NO and standard → Generic

Pattern 4: Bounded Context Size

Too Small:

OrderContext
OrderItemContext        ❌ Gaping holes
OrderStatusContext      ❌ Fragmented

Right Size:

OrderContext            ✅ Complete language
├── Order
├── OrderItem
└── OrderStatus

Too Large:

SalesContext            ❌ Mixed concerns
├── Order
├── Product
├── Customer
└── Invoice

Pattern 5: Integration Types

Synchronous (use sparingly):

• When immediate consistency required
• Example: Order → Payment (need immediate response)

Asynchronous (prefer):

• When eventual consistency acceptable
• Example: Order → Shipping (can be delayed)

Event-Driven (best for decoupling):

• When multiple contexts need to react
• Example: OrderPlaced → [Billing, Shipping, Analytics]

---

Quick Analysis Template

Use this template when analyzing any codebase:

## Codebase: {Name}

### Step 1: Concepts Extracted
- Entities: [list]
- Services: [list]
- Use Cases: [list]
- Controllers: [list]

### Step 2: Language Groups
- Group 1: {name} - terms: [list]
- Group 2: {name} - terms: [list]

### Step 3: Subdomains Identified
1. {Subdomain} (Core/Supporting/Generic)
   - Language: [terms]
   - Concepts: [list]
   - Cohesion: X/10
   - Bounded Context: {Name}Context

### Step 4: Cohesion Matrix
| Domain A | Domain B | Cohesion | Issue |
|----------|----------|----------|-------|
| ... | ... | X/10 | ... |

### Step 5: Issues Found
- Priority High: [list]
- Priority Medium: [list]
- Priority Low: [list]

### Step 6: Recommendations
1. [recommendation]
2. [recommendation]

Quick Reference Card

Decision Trees

Subdomain Classification

┌─────────────────────────────────────────┐
│ Is it a competitive advantage?         │
│ Does it differentiate the business?    │
└─────────────┬───────────────────────────┘
              │
         YES  │  NO
      ┌───────┴────────┐
      ▼                ▼
┌──────────┐    ┌─────────────────────────┐
│   CORE   │    │ Is it business-specific?│
│  DOMAIN  │    │ Requires domain knowledge?
└──────────┘    └────────┬────────────────┘
                         │
                    YES  │  NO
                 ┌───────┴──────┐
                 ▼              ▼
          ┌────────────┐  ┌─────────┐
          │ SUPPORTING │  │ GENERIC │
          │ SUBDOMAIN  │  │SUBDOMAIN│
          └────────────┘  └─────────┘

Bounded Context Detection

┌──────────────────────────────────┐
│ Same term, different meaning?   │
└────────────┬─────────────────────┘
             │
        YES  │  NO
     ┌───────┴──────┐
     ▼              ▼
┌─────────┐   ┌────────────┐
│DIFFERENT│   │    SAME    │
│CONTEXTS │   │  CONTEXT   │
└─────────┘   └────────────┘

Examples:
• "Customer" in Sales vs Support → DIFFERENT
• "Product" everywhere same → SAME (but verify!)

Cohesion Scoring

Quick Score

Linguistic (0-3):
└─ Same vocabulary?
   3 = All terms shared
   2 = Most terms shared
   1 = Some terms shared
   0 = Different vocabulary

Usage (0-3):
└─ Used together?
   3 = Always used together
   2 = Frequently together
   1 = Sometimes together
   0 = Rarely together

Data (0-2):
└─ Direct relationships?
   2 = Direct entity relationships
   1 = Indirect relationships
   0 = No relationships

Change (0-2):
└─ Change together?
   2 = Always change together
   1 = Sometimes together
   0 = Independently

Total: X / 10

Interpretation

8-10 ✅ HIGH
     └─ Strong subdomain candidate
     └─ Good bounded context boundary

5-7  ⚠️ MEDIUM
     └─ Review boundaries
     └─ May need refinement

0-4  ❌ LOW
     └─ Wrong grouping
     └─ Needs separation

Red Flags

Linguistic Issues

❌ User + Subscription in same service
   → Identity mixed with Billing

❌ Movie + Invoice in same context
   → Content mixed with Billing

❌ Authentication + Content in same module
   → Generic mixed with Core

✅ Subscription + Invoice + Payment together
   → All Billing language

Coupling Issues

❌ Direct entity import across domains
   import { User } from '@identity/entities'

❌ Service dependency across domains
   constructor(subscriptionService: SubscriptionService)

❌ Shared database tables across domains
   FOREIGN KEY(user_id) REFERENCES users(id)

✅ Interface-based integration
   constructor(billingApi: IBillingApi)

✅ Event-based communication
   eventBus.publish(new OrderPlaced(...))

✅ Value object sharing
   class Order { customerId: CustomerId }

Common Subdomains

Generic (can outsource)

• Authentication/Authorization
• Email/SMS sending
• File storage
• Logging/Monitoring
• Caching
• Search indexing (basic)

Supporting (business-specific)

• Inventory management
• Order fulfillment
• Content moderation
• User notifications
• Reporting/Analytics
• Invoice generation

Core (competitive advantage)

• Recommendation algorithm (unique)
• Pricing strategy (custom)
• Matching algorithm (proprietary)
• Risk assessment (specialized)
• Forecasting model (custom)

Integration Patterns

When to Use Each

SHARED KERNEL
├─ Use: Rarely, small value objects only
├─ Example: Money, Address, Email
└─ Warning: Creates coupling

CUSTOMER/SUPPLIER
├─ Use: Clear upstream/downstream
├─ Example: Order → Shipping
└─ Pattern: API contract

ANTI-CORRUPTION LAYER
├─ Use: Protecting from external systems
├─ Example: Legacy system integration
└─ Pattern: Translation layer

DOMAIN EVENTS
├─ Use: Multiple consumers, eventual consistency
├─ Example: OrderPlaced → [Billing, Shipping]
└─ Pattern: Pub/Sub

OPEN HOST SERVICE
├─ Use: Published API for others
├─ Example: Payment gateway API
└─ Pattern: REST/GraphQL API

Analysis Checklist

Per Concept

□ Business language identified?
□ Domain assigned?
□ Subdomain assigned?
□ Core/Supporting/Generic classified?
□ Related concepts identified?
□ Dependencies mapped?
□ Linguistic mismatches checked?

Per Domain

□ Ubiquitous Language defined?
□ Key concepts listed?
□ Subdomains identified?
□ Core Domain identified?
□ Cross-domain dependencies mapped?
□ Internal cohesion assessed?
□ Boundaries validated?

Per Bounded Context

□ Linguistic boundary clear?
□ Contains complete model?
□ Integration points defined?
□ No mixed vocabularies?
□ Size appropriate (Mozart Principle)?
□ Not driven by architecture?
□ Not driven by team structure?

Size Guidelines

Too Small

❌ Gaping holes in Ubiquitous Language
❌ Incomplete business capability
❌ Too many integration points
❌ Fragments of concepts

Example:
- ProductContext (only Product)
- InventoryContext (only Stock)
- PricingContext (only Price)
→ Should be: CatalogContext

Just Right

✅ Complete Ubiquitous Language
✅ Full business capability
✅ Clear integration points
✅ Cohesive concepts

Example:
CatalogContext
├── Product
├── Category
├── Inventory
└── Pricing

Too Large

❌ Multiple vocabularies mixed
❌ Multiple business capabilities
❌ Low internal cohesion
❌ Muddy boundaries

Example:
BusinessContext
├── Order (order language)
├── Product (catalog language)
├── User (identity language)
└── Payment (billing language)
→ Should be: 4 separate contexts

Common Mistakes

Mistake 1: Grouping by Technical Layer

❌ WRONG:
- ControllerContext
- ServiceContext
- RepositoryContext

✅ RIGHT:
- OrderContext (all layers for orders)
- ProductContext (all layers for products)

Mistake 2: Sharing Entities Directly

❌ WRONG:
class Order {
  user: User;  // Full entity from Identity
}

✅ RIGHT:
class Order {
  customerId: CustomerId;  // Value object
}

Mistake 3: One Size Fits All

❌ WRONG: Force all domains to have same size

✅ RIGHT: Size based on Ubiquitous Language
- Small domain: 3-5 concepts (if complete)
- Medium domain: 6-15 concepts
- Large domain: 16+ concepts (if cohesive)

Mistake 4: Technical Boundaries

❌ WRONG: Bounded contexts for:
- Frontend vs Backend
- Microservice per entity
- One context per database

✅ RIGHT: Linguistic boundaries:
- Where terms have specific meanings
- Where business capabilities are distinct

Key Questions

For Subdomain Classification

1. Does this provide competitive advantage?
2. Is it business-specific or generic?
3. Is it essential to core business?
4. Could we outsource it?
5. How often does it change?
6. Does it require domain experts?

For Bounded Context Definition

1. Does this term have different meanings elsewhere?
2. Can we define all terms unambiguously here?
3. Is this a complete business capability?
4. Are all concepts linguistically related?
5. Where do we translate between contexts?
6. What are the integration points?

For Cohesion Assessment

1. Do these concepts share vocabulary?
2. Are they used together frequently?
3. Do changes affect them together?
4. Do they solve the same business problem?
5. Are they in the same lifecycle?
6. Do they have direct relationships?

Signal Words

Core Domain Signals

"competitive advantage"
"unique to our business"
"our secret sauce"
"what makes us different"
"complex business rules"
"needs domain experts"

Supporting Signals

"necessary but standard"
"business-specific"
"supports core operations"
"moderate complexity"
"internal tool"

Generic Signals

"could buy this"
"standard functionality"
"well-known solution"
"common to all businesses"
"infrastructure"

Low Cohesion Signals

"mixed concerns"
"different vocabularies"
"unrelated concepts"
"tight coupling"
"unclear boundary"
"linguistic mismatch"

Subdomain Identification Skill

A Agent Skill for identifying subdomains and suggesting bounded contexts in any codebase following Domain-Driven Design (DDD) Strategic Design principles.

What This Skill Does

This skill analyzes codebases to:

1. Extract business concepts from code (entities, services, use cases, controllers) 2. Group concepts by Ubiquitous Language (business vocabulary) 3. Identify subdomains and classify them as Core, Supporting, or Generic 4. Assess cohesion within and across domains 5. Detect low cohesion issues and coupling problems 6. Suggest bounded contexts with clear linguistic boundaries 7. Provide actionable recommendations for domain separation

When the Agent Uses This Skill

The agent automatically applies this skill when you:

• Ask to analyze domain boundaries
• Request subdomain identification
• Need help with DDD strategic design
• Want to assess domain cohesion
• Ask about bounded contexts
• Discuss domain-driven refactoring
• Inquire about business capabilities in code

Key Features

Generic & Portable

This skill is designed to work with any codebase in any language:

• No framework-specific assumptions
• Language-agnostic principles
• Focuses on business concepts, not technical implementation
• Can analyze monoliths, microservices, or hybrid architectures

DDD Strategic Design Foundation

Based on proven Domain-Driven Design principles:

• Problem Space: Identifies subdomains (Core, Supporting, Generic)
• Solution Space: Suggests bounded contexts with clear boundaries
• Ubiquitous Language: Primary driver for boundary detection
• Cohesion Analysis: Objective metrics for domain relationships

Actionable Output

Provides concrete, actionable analysis:

• Domain maps with cohesion scores
• Cross-domain cohesion matrices
• Low cohesion issue reports with priorities
• Bounded context suggestions with integration patterns
• Clear recommendations for improvement

Files Included

SKILL.md (Main Skill)

The primary skill file containing:

• Complete analysis process (6 phases)
• Subdomain classification rules
• Cohesion assessment framework
• Low cohesion detection rules
• Output format templates
• Best practices and anti-patterns

EXAMPLES.md (Practical Examples)

Real-world examples across different domains:

• E-Commerce Platform
• Healthcare System
• SaaS Project Management Tool
• Streaming Video Platform
• Common patterns and solutions
• Quick analysis template

QUICK-REFERENCE.md (Quick Lookup)

Fast reference for common scenarios:

• Decision trees for classification
• Cohesion scoring shortcuts
• Red flags and signals
• Integration pattern guide
• Common mistakes to avoid
• Key questions for assessment

Usage Examples

Example 1: Analyze Entire Codebase

User: "Analyze the domains in this codebase and suggest bounded contexts"

Agent: [Uses skill to:]
1. Extract all business concepts
2. Group by Ubiquitous Language
3. Identify subdomains
4. Calculate cohesion scores
5. Detect issues
6. Suggest bounded contexts

Example 2: Check Specific Module

User: "Is the billing module properly separated from other domains?"

Agent: [Uses skill to:]
1. Analyze billing module concepts
2. Check cross-domain dependencies
3. Assess linguistic cohesion
4. Flag coupling issues
5. Recommend improvements

Example 3: Classify Subdomain

User: "Should our recommendation engine be Core or Supporting?"

Agent: [Uses skill to:]
1. Ask: Is it competitive advantage?
2. Assess business differentiation
3. Check complexity & change frequency
4. Classify using decision tree
5. Explain classification

Core Concepts

Subdomain Types

Core Domain

• Your competitive advantage
• What makes your business unique
• Requires best developers and domain experts
• Example: Netflix's recommendation algorithm

Supporting Subdomain

• Essential but not differentiating
• Business-specific but not unique
• Supports the Core Domain
• Example: Custom inventory management rules

Generic Subdomain

• Common functionality
• Could be outsourced or purchased
• Well-understood solutions
• Example: User authentication, email sending

Cohesion Scoring

The skill uses a 10-point cohesion scale:

Score = Linguistic (0-3) + Usage (0-3) + Data (0-2) + Change (0-2)

8-10: High Cohesion ✅ (Strong subdomain candidate)
5-7:  Medium Cohesion ⚠️ (Review boundaries)
0-4:  Low Cohesion ❌ (Wrong grouping, needs separation)

Bounded Context

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

• Primary driver: Business language, not technical architecture
• Goal: Align 1 Subdomain to 1 Bounded Context
• Integration: Use interfaces, events, or APIs between contexts
• Size: As big as needed to express complete Ubiquitous Language

Key Principles

1. Language Over Architecture: Bounded contexts are linguistic boundaries, not technical ones 2. Business Over Technical: Focus on business capabilities, not code structure 3. Cohesion is Measurable: Use objective metrics, not gut feeling 4. Context is King: Same term can mean different things in different contexts 5. Integration is Necessary: Some cross-domain dependencies are normal and healthy

Anti-Patterns Detected

The skill identifies common mistakes:

• Big Ball of Mud: Everything connected to everything
• All-Inclusive Model: Trying to create single global model
• Mixed Linguistic Concepts: Different vocabularies in same context
• Cross-Domain Tight Coupling: Direct entity references between domains
• Generic in Core: Infrastructure concerns in business logic
• Unclear Boundaries: Cannot determine which domain owns concept

Integration Patterns

The skill suggests appropriate integration patterns:

• Domain Events: For decoupled, eventual consistency
• API/Interface: For synchronous integration with clear contract
• Anti-Corruption Layer: For protecting from external systems
• Published Language: For stable, documented integration
• Customer/Supplier: For clear upstream/downstream relationships

Installation

This skill is installed at the project level in your agent's skills directory:

.{agent}/skills/subdomain-identification/

Where {agent} is your agent's directory (e.g., .cursor/, .claude/, .agent/, .github/, .opencode/).

This means it's:

• Shared with the repository: Anyone cloning this repo gets the skill
• Version controlled: Changes are tracked in git
• Project-specific: Can be customized for this codebase

The agent will automatically discover and use it when appropriate based on the description in the frontmatter.

Customization

For Project-Specific Domains

If your project has specific domain patterns, create a project-level reference:

.{agent}/skills/subdomain-identification/
└── project-domains.md  # Document project-specific patterns

Link to it from your analysis requests.

For Framework-Specific Analysis

Add framework-specific patterns to help the skill:

## Framework: NestJS

**Entity Pattern**: `@Entity()` decorator
**Service Pattern**: `@Injectable()` classes ending in `Service`
**Controller Pattern**: `@Controller()` decorator
**Use Case Pattern**: Classes ending in `UseCase`

Validation

To verify the skill works correctly, try:

User: "What subdomains can you identify in this codebase?"

The agent should:

1. Read the SKILL.md file 2. Follow the 6-phase analysis process 3. Output domain maps and cohesion matrices 4. Provide actionable recommendations

References

This skill is based on:

• Domain-Driven Design by Eric Evans
• Implementing Domain-Driven Design by Vaughn Vernon
• Strategic Design principles from the DDD community

License

This skill can be used, modified, and shared freely. It's designed to be portable across any codebase or organization.

Contributing

To improve this skill:

1. Add more examples to EXAMPLES.md 2. Expand the quick reference with new patterns 3. Add language/framework-specific detection patterns 4. Document new anti-patterns or red flags 5. Share real-world case studies

Version

Version: 1.0.0 Created: 2026-02-05 Based on: DDD Strategic Design Theory

---

Quick Start

To use this skill immediately:

User: "Analyze domains in my codebase"
User: "Identify subdomains and suggest bounded contexts"
User: "Check cohesion between [DomainA] and [DomainB]"
User: "Is [concept] Core, Supporting, or Generic?"

The agent will automatically apply this skill and provide comprehensive analysis.