Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
yonatangross avatar

Domain Driven Design

  • 885 installs
  • 213 repo stars
  • Updated August 4, 2026
  • yonatangross/orchestkit

domain-driven-design is a backend architecture skill that applies strategic and tactical DDD checklists so developers align services, entities, and bounded contexts with real business domains.

About

domain-driven-design is a Domain-Driven Design checklist skill from yonatangross/orchestkit that guides developers through strategic design (bounded contexts, context maps, ubiquitous language) and tactical design (entities, value objects, aggregates). The skill prompts verification that domain boundaries are documented, integration patterns are chosen, and code uses context-specific terminology instead of generic technical jargon. Developers reach for domain-driven-design when backend services grow entangled or when product language and code diverge during feature work. The checklist spans ownership, glossary terms, UUID-based entity identity, and relationship patterns such as anti-corruption layers and shared kernels.

  • Strategic Design checklist covering Bounded Contexts, Context Maps, and Ubiquitous Language
  • Tactical Design checklist with 5 focused sections: Entities, Value Objects, Aggregates, Repositories, and Domain Events
  • 28-item comprehensive DDD checklist that enforces rich domain models over anemic ones
  • Hard-gate review before committing new domain logic
  • Next-skill handoff to implementation once aggregate boundaries are approved

Domain Driven Design by the numbers

  • 885 all-time installs (skills.sh)
  • +50 installs in the week ending Aug 5, 2026 (Skillselion tracking)
  • Ranked #547 of 3,282 Productivity & Planning skills by installs in the Skillselion catalog
  • Security screen: LOW risk (skills.sh audit)
  • Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/yonatangross/orchestkit --skill domain-driven-design

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs885
repo stars213
Security audit3 / 3 scanners passed
Last updatedAugust 4, 2026
Repositoryyonatangross/orchestkit

How do you apply DDD to a growing backend?

Apply Domain-Driven Design principles so their backend code stays aligned with real business problems instead of becoming a tangle of technical shortcuts.

Who is it for?

Backend developers modeling complex business domains who need a structured DDD audit before or during service refactors.

Skip if: Skip domain-driven-design when the codebase is a small CRUD prototype with no evolving business vocabulary or cross-team domain boundaries.

When should I use this skill?

Trigger when the user asks about bounded contexts, ubiquitous language, DDD entities, context maps, or aligning backend code with business terminology.

What you get

Bounded-context map, ubiquitous-language glossary, entity identity rules, and integration-pattern decisions documented for the backend.

  • Bounded-context documentation
  • Ubiquitous-language glossary
  • Entity and integration-pattern checklist

By the numbers

  • Covers strategic and tactical DDD checklist sections including bounded contexts and entities

Files

SKILL.mdMarkdownGitHub ↗

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)

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)

Load Read("${CLAUDE_SKILL_DIR}/references/entities-value-objects.md") for complete patterns.

Value Object (Immutable)

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)

Load Read("${CLAUDE_SKILL_DIR}/references/entities-value-objects.md") for Address, DateRange examples.

Key Decisions

DecisionRecommendation
Entity vs VOHas unique ID + lifecycle? Entity. Otherwise VO
Entity equalityBy ID, not attributes
Value object mutabilityAlways immutable (frozen=True)
Repository scopeOne per aggregate root
Domain eventsCollect in entity, publish after persist
Context boundariesBy business capability, not technical

Rules Quick Reference

RuleImpactWhat It Covers
aggregate-boundaries (load ${CLAUDE_SKILL_DIR}/rules/aggregate-boundaries.md)HIGHAggregate root design, reference by ID, one-per-transaction
aggregate-invariants (load ${CLAUDE_SKILL_DIR}/rules/aggregate-invariants.md)HIGHBusiness rule enforcement, specification pattern
aggregate-sizing (load ${CLAUDE_SKILL_DIR}/rules/aggregate-sizing.md)HIGHRight-sizing, when to split, eventual consistency

When NOT to Use

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

PatternInterviewHackathonMVPGrowthEnterpriseSimpler Alternative
AggregatesOVERKILLOVERKILLOVERKILLSELECTIVEAPPROPRIATEPlain dataclasses with validation
Bounded contextsOVERKILLOVERKILLOVERKILLBORDERLINEAPPROPRIATEPython packages with clear imports
CQRSOVERKILLOVERKILLOVERKILLOVERKILLWHEN JUSTIFIEDSingle model for read/write
Value objectsOVERKILLOVERKILLBORDERLINEAPPROPRIATEREQUIREDTyped fields on the entity
Domain eventsOVERKILLOVERKILLOVERKILLSELECTIVEAPPROPRIATEDirect method calls between services
Repository patternOVERKILLOVERKILLBORDERLINEAPPROPRIATEREQUIREDDirect 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)

# 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
  • ork:distributed-systems - Cross-aggregate coordination
  • ork:database-patterns - Schema design for DDD

References

Load on demand with Read("${CLAUDE_SKILL_DIR}/references/<file>"):

FileContent
entities-value-objects.mdFull entity and value object patterns
repositories.mdRepository pattern implementation
domain-events.mdEvent collection and publishing
bounded-contexts.mdContext 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

Related skills

How it compares

Pick domain-driven-design for structured DDD architecture audits; use framework-specific backend skills when the task is API wiring rather than domain modeling.

FAQ

What does the domain-driven-design skill cover?

The domain-driven-design skill provides checklists for strategic design (bounded contexts, context maps, ubiquitous language) and tactical design (entities identified by UUID, equality by ID). Developers use it to align backend code with business domain language.

When should developers use domain-driven-design?

Developers should use domain-driven-design when backend services accumulate technical shortcuts, domain terms diverge from code, or multiple teams need clear context boundaries. The skill structures audits before refactors or greenfield service design.

Is Domain Driven Design safe to install?

skills.sh reports 3 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.

Productivity & Planningbackendintegrations

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.