ddd-modellisted

# Domain-Driven Design Modeling Map a domain into bounded contexts, aggregates, entities, value objects, and context relationships. Arguments: `$ARGUMENTS` - domain name or description, or `audit` to assess DDD fitness of existing codebase ## Behavior ### 1. Assess DDD Fitness (when `audit` or no clear domain given) ```bash # Check size and complexity signals find . -type f \( -name "*.py" -o -name "*.ts" -o -name "*.java" \) \ -not -path "*/node_modules/*" -not -path "*/.git/*" | wc -l # Look for existing domain structure signals find . -type d \( -name "domain" -o -name "entities" -o -name "aggregates" \ -o -name "repositories" -o -name "services" \) 2>/dev/null | head -10 # Check for anemic domain model anti-patterns grep -rn "class.*DTO\|class.*Model\b\|class.*Entity" . \ --include="*.py" --include="*.ts" -l 2>/dev/null | head -10 ``` DDD is a good fit when: domain logic is complex, multiple teams work on the same system, or the business rules change frequently. Skip it for CRUD-heavy apps with simple logic. ### 2. Bounded Context Discovery Ask clarifying questions to identify contexts: - What are the main business capabilities? (e.g., ordering, inventory, billing) - Which teams own which parts of the system? - Where do the same words mean different things? (e.g., "customer" in sales vs. support) - What are the consistency requirements? (what must change together?) Output a context map: ``` Domain: E-Commerce Platform ━━━━━━━━━━━━━━━━━━━━━━━━━━ Bounded