home / skills / pluginagentmarketplace / custom-plugin-software-design / domain-driven-design

domain-driven-design skill

/skills/domain-driven-design

This skill helps you model domains using domain-driven design patterns to create clear contexts, aggregates, and ubiquitous language.

npx playbooks add skill pluginagentmarketplace/custom-plugin-software-design --skill domain-driven-design

Review the files below or copy the command above to add this skill to your agents.

Files (6)
SKILL.md
4.4 KB
---
name: domain-driven-design
description: Model business domains using DDD tactical and strategic patterns
sasmp_version: "1.3.0"
bonded_agent: 05-domain-driven
bond_type: PRIMARY_BOND
version: "2.0.0"
updated: "2025-12-30"
---

# Domain-Driven Design Skill

> Atomic skill for domain modeling and DDD pattern application

## Skill Definition

```yaml
skill_id: domain-driven-design
responsibility: Single - Domain modeling and DDD pattern guidance
atomic: true
idempotent: true
```

## Parameter Schema

```typescript
interface SkillParams {
  // Required
  action: 'model' | 'aggregate' | 'context_map' | 'event_storm';
  domain_description: string;

  // Optional
  existing_models?: string;
  stakeholder_terms?: string[];
  complexity?: 'core' | 'supporting' | 'generic';
  output_format?: 'text' | 'code' | 'diagram';
}

interface SkillResult {
  domain_model?: DomainModel;
  aggregates?: AggregateDefinition[];
  context_map?: ContextMap;
  event_storm?: EventStormResult;
  ubiquitous_language?: GlossaryEntry[];
}
```

## Validation Rules

```yaml
input_validation:
  action:
    required: true
    enum: [model, aggregate, context_map, event_storm]

  domain_description:
    required: true
    min_length: 50
    max_length: 10000
```

## Retry Logic

```yaml
retry_config:
  max_attempts: 3
  backoff:
    type: exponential
    initial_delay_ms: 1500
    max_delay_ms: 15000
    multiplier: 2

  retryable_errors:
    - TIMEOUT
    - RATE_LIMIT

  non_retryable_errors:
    - INSUFFICIENT_DOMAIN_INFO
```

## DDD Building Blocks

### Tactical Patterns

```yaml
entity:
  characteristics:
    - Has identity
    - Has lifecycle
    - Can change state
  example:
    name: Order
    identity: orderId

value_object:
  characteristics:
    - No identity
    - Immutable
    - Equality by attributes
  example:
    name: Money
    attributes: [amount, currency]

aggregate:
  characteristics:
    - Consistency boundary
    - Single root entity
    - Transactional unit
  rules:
    - Reference by ID only
    - Single aggregate per transaction
```

### Strategic Patterns

```yaml
bounded_context:
  identification:
    - Linguistic boundary
    - Team ownership
    - Model consistency scope

context_map_patterns:
  - partnership
  - customer_supplier
  - conformist
  - anticorruption_layer
  - open_host_service
```

## Usage Examples

### Domain Modeling
```typescript
// Input
{
  action: "model",
  domain_description: `
    E-commerce order management system. Customers place orders
    containing multiple products.
  `
}

// Output
{
  domain_model: {
    entities: [
      { name: "Order", identity: "orderId" },
      { name: "Customer", identity: "customerId" }
    ],
    value_objects: [
      { name: "Address", attributes: ["street", "city", "zip"] },
      { name: "Money", attributes: ["amount", "currency"] }
    ],
    aggregates: [
      {
        name: "Order",
        root_entity: "Order",
        entities: ["OrderLine"],
        invariants: ["Order total must equal sum of line totals"]
      }
    ]
  },
  ubiquitous_language: [
    { term: "Order", definition: "A customer's request to purchase products" }
  ]
}
```

## Unit Test Template

```typescript
describe('DomainDrivenDesignSkill', () => {
  describe('model', () => {
    it('should identify entities from domain description', async () => {
      const result = await skill.execute({
        action: 'model',
        domain_description: 'Customers place orders for products'
      });

      expect(result.domain_model.entities.map(e => e.name))
        .toContain('Customer');
    });
  });

  describe('aggregate', () => {
    it('should define aggregate boundaries based on invariants', async () => {
      const result = await skill.execute({
        action: 'aggregate',
        domain_description: 'Order with lines, total must match'
      });

      expect(result.aggregates[0].invariants).toBeDefined();
    });
  });
});
```

## Error Handling

```yaml
errors:
  INSUFFICIENT_DOMAIN_INFO:
    code: 400
    message: "Domain description lacks sufficient detail"
    recovery: "Provide more business context and rules"

  AMBIGUOUS_BOUNDARIES:
    code: 422
    message: "Cannot determine clear aggregate boundaries"
    recovery: "Clarify invariants and transactional requirements"
```

## Integration

```yaml
requires:
  - nlp_analyzer
  - domain_extractor

emits:
  - domain_modeled
  - aggregate_defined
  - context_mapped

consumed_by:
  - 05-domain-driven (bonded agent)
  - 07-architecture-patterns (for architecture mapping)
```

Overview

This skill helps model business domains using Domain-Driven Design (DDD) tactical and strategic patterns. It produces domain models, aggregate boundaries, context maps, and event-storm artifacts from natural language domain descriptions. The output is tailored to clarity for teams: entities, value objects, aggregates, ubiquitous language, and recommended context relationships.

How this skill works

Provide a domain description and select an action: model, aggregate, context_map, or event_storm. The skill analyzes language, extracts candidate entities, value objects, invariants, and teams/language boundaries, then synthesizes concrete artifacts in text, code, or diagram-friendly formats. Validation ensures sufficient domain detail and returns actionable guidance or requests more context when boundaries are ambiguous.

When to use it

  • Designing or refactoring a bounded context for a new or existing system
  • Defining aggregate boundaries and invariants before implementation
  • Creating a shared ubiquitous language for cross-functional teams
  • Mapping relationships between contexts and integration patterns
  • Running event-storming workshops to discover domain events and commands

Best practices

  • Provide at least a paragraph (50+ characters) of domain context including business goals and key rules
  • Highlight invariants, transactional expectations, and ownership to clarify aggregate scope
  • Capture stakeholder terminology to build the ubiquitous language and reduce ambiguity
  • Prefer iterative outputs: start with a model action, then refine aggregates and context maps
  • Use the skill output as input to design discussions, not as a final implementation artifact

Example use cases

  • Generate an initial domain model from an e-commerce order and payment description
  • Define an Order aggregate with invariants like order total consistency and payment state transitions
  • Produce a context map showing a conformist relationship between payment and order contexts
  • Run an event-storm action to list domain events, commands, and hot spots for process discovery
  • Convert stakeholder terms into a concise ubiquitous language glossary for team alignment

FAQ

What if my domain description is short or vague?

The skill requires sufficient detail; it will return an INSUFFICIENT_DOMAIN_INFO response and ask for more business rules, actors, or examples.

Can it output diagrams?

Yes — choose output_format 'diagram' for diagram-friendly descriptions or 'code' for structured JSON or Python-friendly representations.

How does it decide aggregate boundaries?

It uses invariants, transactional requirements, and identity ownership to propose aggregates and flags ambiguous cases requiring clarification.