home / skills / yonatangross / orchestkit / domain-driven-design

domain-driven-design skill

/plugins/ork/skills/domain-driven-design

This skill applies domain-driven design tactical patterns to model entities, value objects, and bounded contexts in complex business domains.

npx playbooks add skill yonatangross/orchestkit --skill domain-driven-design

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

Files (14)
SKILL.md
7.1 KB
---
name: domain-driven-design
license: MIT
compatibility: "Claude Code 2.1.34+."
description: Domain-Driven Design tactical patterns for complex business domains. Use when modeling entities, value objects, domain services, repositories, or establishing bounded contexts.
context: fork
agent: backend-system-architect
version: 1.0.0
tags: [ddd, domain-modeling, entities, value-objects, bounded-contexts, python]
author: OrchestKit
user-invocable: false
complexity: medium
metadata:
  category: document-asset-creation
---

# Domain-Driven Design Tactical Patterns

Model complex business domains with entities, value objects, and bounded contexts.

## Overview

- Modeling complex business logic
- Separating domain from infrastructure
- Establishing clear boundaries between subdomains
- Building rich domain models with behavior
- Implementing ubiquitous language in code

## Building Blocks Overview

```
┌─────────────────────────────────────────────────────────────┐
│                    DDD Building Blocks                       │
├─────────────────────────────────────────────────────────────┤
│  ENTITIES           VALUE OBJECTS        AGGREGATES         │
│  Order (has ID)     Money (no ID)        [Order]→Items      │
│                                                              │
│  DOMAIN SERVICES    REPOSITORIES         DOMAIN EVENTS      │
│  PricingService     IOrderRepository     OrderSubmitted     │
│                                                              │
│  FACTORIES          SPECIFICATIONS       MODULES            │
│  OrderFactory       OverdueOrderSpec     orders/, payments/ │
└─────────────────────────────────────────────────────────────┘
```

## Quick Reference

### Entity (Has Identity)

```python
from dataclasses import dataclass, field
from uuid import UUID
from uuid_utils import uuid7

@dataclass
class Order:
    """Entity: Has identity, mutable state, lifecycle."""
    id: UUID = field(default_factory=uuid7)
    customer_id: UUID = field(default=None)
    status: str = "draft"

    def __eq__(self, other: object) -> bool:
        if not isinstance(other, Order):
            return NotImplemented
        return self.id == other.id  # Identity equality

    def __hash__(self) -> int:
        return hash(self.id)
```

See [entities-value-objects.md](references/entities-value-objects.md) for complete patterns.

### Value Object (Immutable)

```python
from dataclasses import dataclass
from decimal import Decimal

@dataclass(frozen=True)  # MUST be frozen!
class Money:
    """Value Object: Defined by attributes, not identity."""
    amount: Decimal
    currency: str

    def __add__(self, other: "Money") -> "Money":
        if self.currency != other.currency:
            raise ValueError("Cannot add different currencies")
        return Money(self.amount + other.amount, self.currency)
```

See [entities-value-objects.md](references/entities-value-objects.md) for Address, DateRange examples.

## Key Decisions

| Decision | Recommendation |
|----------|----------------|
| Entity vs VO | Has unique ID + lifecycle? Entity. Otherwise VO |
| Entity equality | By ID, not attributes |
| Value object mutability | Always immutable (`frozen=True`) |
| Repository scope | One per aggregate root |
| Domain events | Collect in entity, publish after persist |
| Context boundaries | By business capability, not technical |

## Rules Quick Reference

| Rule | Impact | What It Covers |
|------|--------|----------------|
| [aggregate-boundaries](rules/aggregate-boundaries.md) | HIGH | Aggregate root design, reference by ID, one-per-transaction |
| [aggregate-invariants](rules/aggregate-invariants.md) | HIGH | Business rule enforcement, specification pattern |
| [aggregate-sizing](rules/aggregate-sizing.md) | HIGH | Right-sizing, when to split, eventual consistency |

## When NOT to Use

Under 5 entities? Skip DDD entirely. The ceremony costs more than the benefit.

| Pattern | Interview | Hackathon | MVP | Growth | Enterprise | Simpler Alternative |
|---------|-----------|-----------|-----|--------|------------|---------------------|
| Aggregates | OVERKILL | OVERKILL | OVERKILL | SELECTIVE | APPROPRIATE | Plain dataclasses with validation |
| Bounded contexts | OVERKILL | OVERKILL | OVERKILL | BORDERLINE | APPROPRIATE | Python packages with clear imports |
| CQRS | OVERKILL | OVERKILL | OVERKILL | OVERKILL | WHEN JUSTIFIED | Single model for read/write |
| Value objects | OVERKILL | OVERKILL | BORDERLINE | APPROPRIATE | REQUIRED | Typed fields on the entity |
| Domain events | OVERKILL | OVERKILL | OVERKILL | SELECTIVE | APPROPRIATE | Direct method calls between services |
| Repository pattern | OVERKILL | OVERKILL | BORDERLINE | APPROPRIATE | REQUIRED | Direct ORM queries in service layer |

**Rule of thumb:** DDD adds ~40% code overhead. Only worth it when domain complexity genuinely demands it (5+ entities with invariants spanning multiple objects). A CRUD app with DDD is a red flag.

## Anti-Patterns (FORBIDDEN)

```python
# NEVER have anemic domain models (data-only classes)
@dataclass
class Order:
    id: UUID
    items: list  # WRONG - no behavior!

# NEVER leak infrastructure into domain
class Order:
    def save(self, session: Session):  # WRONG - knows about DB!

# NEVER use mutable value objects
@dataclass  # WRONG - missing frozen=True
class Money:
    amount: Decimal

# NEVER have repositories return ORM models
async def get(self, id: UUID) -> OrderModel:  # WRONG - return domain!
```

## Related Skills

- `aggregate-patterns` - Deep dive on aggregate design
- `distributed-systems` - Cross-aggregate coordination
- `database-patterns` - Schema design for DDD

## References

- [Entities & Value Objects](references/entities-value-objects.md) - Full patterns
- [Repositories](references/repositories.md) - Repository pattern implementation
- [Domain Events](references/domain-events.md) - Event collection and publishing
- [Bounded Contexts](references/bounded-contexts.md) - Context mapping and ACL

## Capability Details

### entities
**Keywords:** entity, identity, lifecycle, mutable, domain object
**Solves:** Model entities in Python, identity equality, adding behavior

### value-objects
**Keywords:** value object, immutable, frozen, dataclass, structural equality
**Solves:** Create immutable value objects, when to use VO vs entity

### domain-services
**Keywords:** domain service, business logic, cross-aggregate, stateless
**Solves:** When to use domain service, logic spanning aggregates

### repositories
**Keywords:** repository, persistence, collection, IRepository, protocol
**Solves:** Implement repository pattern, abstract DB access, ORM mapping

### bounded-contexts
**Keywords:** bounded context, context map, ACL, subdomain, ubiquitous language
**Solves:** Define bounded contexts, integrate with ACL, context relationships

Overview

This skill provides Domain-Driven Design (DDD) tactical patterns to model complex business domains using entities, value objects, aggregates, domain services, repositories, and bounded contexts. It focuses on separating domain logic from infrastructure and encoding business behavior and invariants into the domain model. Use it to design maintainable, expressive models that reflect the ubiquitous language of the business.

How this skill works

The skill describes concrete building blocks (entities with identity, immutable value objects, aggregates, domain services, factories, repositories, and domain events) and rules for their composition. It explains identity and equality rules, aggregate boundaries and sizing, when to collect and publish domain events, and how to keep infrastructure out of the domain. Practical anti-patterns and trade-offs (when DDD is overkill) are included to guide adoption.

When to use it

  • Designing systems with rich business logic and invariants that span multiple objects or processes
  • When you need clear boundaries between subdomains and a ubiquitous language between domain experts and engineers
  • Building services where consistency, lifecycle, and identity matter (payment orders, workflows, bookings)
  • When repository and domain event patterns improve testability and separation of concerns
  • For enterprise systems or growth-stage products where long-term maintainability outweighs initial overhead

Best practices

  • Model entities when objects have identity and lifecycle; use value objects for immutable, attribute-defined concepts
  • Enforce business rules at aggregate roots and prefer references by ID across aggregates to avoid transactional cross-aggregate mutations
  • Keep domain code infrastructure-free: repositories return domain objects, not ORM models, and publishing events happens after persistence
  • Make value objects immutable and implement structural equality; make entity equality identity-based
  • Avoid DDD ceremony for trivial apps (fewer than ~5 domain entities); adopt selectively as complexity grows

Example use cases

  • Order and payment domains: Order aggregate, Money value object, Pricing domain service, OrderSubmitted domain event
  • Subscription billing: immutable Money and DateRange value objects, BillingService as a domain service, subscription aggregate root
  • Complex workflows: model lifecycle transitions in aggregates and publish domain events for downstream processors
  • Bounded contexts: split product catalog and fulfillment into separate contexts with anti-corruption layers and ACLs
  • Data access abstraction: implement repositories per aggregate root to decouple domain tests from the database

FAQ

When is DDD too heavy?

If your application has fewer than about five entities or is a simple CRUD app, DDD often adds unnecessary overhead; simpler patterns or plain dataclasses with validation are better.

Should repositories return ORM models?

No. Repositories should return domain objects to preserve the domain model and keep infrastructure details encapsulated.