ddd

Domain Driven Design

Apply these patterns when implementing domain logic in TypeScript/Deno.

Building Block Selection

Choose the appropriate type based on these criteria:

Quick Decision Flow

Does it have a unique identity that matters?
├─ No → Value Object
└─ Yes → Does it enforce invariants over child objects?
         ├─ Yes → Aggregate Root
         └─ No → Entity (likely part of an aggregate)

TypeScript Patterns

See references/patterns.md for implementation examples.

Ubiquitous Language

Update the project's ubiquitous language glossary when:

• New domain concept introduced (add term + definition)
• Meaning clarified through discussion (refine definition)
• Naming conflicts discovered (resolve and document)
• Bounded context boundary identified (note context for term)

Location: Document terms in code via types/interfaces. Add non-obvious terms to project documentation.

Naming Rules

• Use domain expert terminology, not technical jargon
• Prefer nouns for entities/value objects: Order, Money, Address
• Prefer verbs for domain services: PricingService, ShippingCalculator
• Name aggregates by their root: Order (not OrderAggregate)

Anti-Patterns to Avoid

• Anemic domain model: Entities with only getters/setters, logic in services
• God aggregate: Too many entities under one root (split by invariant boundary)
• Repository per entity: Only aggregate roots get repositories
• Leaking persistence: Domain objects should not know about storage