{
  "id": "page:library-domain-driven-design",
  "_kind": "Page",
  "_file": "wiki/library/domain-driven-design.md",
  "_cluster": "wiki",
  "attributes": {
    "nodeKind": "Page",
    "title": "Domain-Driven Design (DDD) Methodology (Library)",
    "displayName": "Domain-Driven Design (DDD) Methodology (Library)",
    "slug": "library/domain-driven-design",
    "articlePath": "wiki/library/domain-driven-design.md",
    "article": "\n# Domain-Driven Design (DDD) Methodology\n\n**Creator**: Eric Evans\n**Year**: 2003\n**Category**: Strategic Design / Tactical Design / Architecture\n\n## Overview\n\nDomain-Driven Design is an approach for building complex software systems that places the business domain at the center of development. It provides both strategic patterns for organizing large systems and tactical patterns for modeling domain logic.\n\nThis process implements Eric Evans' DDD methodology through the Babysitter SDK orchestration framework, providing agent-driven strategic and tactical design workflows.\n\n## Key Concepts\n\n### Strategic Design (Problem Space)\n\nStrategic design focuses on understanding and organizing the business domain:\n\n- **Ubiquitous Language**: Shared vocabulary between domain experts and developers\n- **Bounded Contexts**: Specific areas where a model/language is consistently used\n- **Context Mapping**: Define relationships between bounded contexts\n- **Subdomains**: Classify as Core (key differentiator), Supporting (necessary but not core), or Generic (off-the-shelf)\n\n### Tactical Design (Solution Space)\n\nTactical design provides patterns for implementing the domain model:\n\n- **Entities**: Objects with unique identity (e.g., Customer, Order)\n- **Value Objects**: Immutable values without identity (e.g., Money, Address)\n- **Aggregates**: Clusters of entities/value objects treated as a unit\n- **Repositories**: Abstract persistence of aggregates\n- **Domain Services**: Operations that don't belong to entities\n- **Domain Events**: Significant occurrences in the domain\n- **Factories**: Complex object creation\n\n## Process Workflow\n\nThe DDD process follows a four-phase workflow:\n\n### Phase 1: Strategic Design\n\n1. **Identify Subdomains** - Classify business domain into Core, Supporting, and Generic subdomains\n2. **Define Bounded Contexts** - Establish clear boundaries where models are consistent\n3. **Create Context Map** - Map relationships and integration patterns between contexts\n4. **Build Ubiquitous Language** (Initial) - Create shared vocabulary glossary\n\n### Phase 2: Tactical Design\n\nFor each bounded context:\n\n1. **Identify Entities and Value Objects** - Model objects with and without identity\n2. **Define Aggregates** - Group entities/VOs into consistency boundaries\n3. **Design Repositories** - Abstract persistence for aggregate roots\n4. **Identify Domain Services** - Operations that don't belong to entities\n\n### Phase 3: Domain Event Modeling\n\n1. **Identify Domain Events** - Significant occurrences in the domain\n2. **Model Event Handlers** - Design handlers and eventual consistency patterns\n\n### Phase 4: Refinement & Implementation\n\n1. **Refine Ubiquitous Language** - Update vocabulary based on tactical design\n2. **Validate Language Consistency** - Ensure consistent usage across artifacts\n3. **Generate Implementation Plans** - Module structure, APIs, integration patterns\n4. **Validate Domain Model** - Final quality check\n\n## Usage\n\n### Full DDD Workflow\n\n```javascript\nimport { orchestrate } from '@a5c-ai/babysitter-sdk';\n\nconst result = await orchestrate({\n  process: 'methodologies/domain-driven-design',\n  inputs: {\n    projectName: 'E-Commerce Platform',\n    domainDescription: 'Online marketplace connecting buyers and sellers...',\n    complexity: 'complex',\n    phase: 'full'\n  }\n});\n```\n\n### Strategic Design Only\n\n```javascript\nconst result = await orchestrate({\n  process: 'methodologies/domain-driven-design',\n  inputs: {\n    projectName: 'E-Commerce Platform',\n    domainDescription: 'Online marketplace...',\n    phase: 'strategic'\n  }\n});\n```\n\n### Tactical Design (with existing strategic design)\n\n```javascript\nconst result = await orchestrate({\n  process: 'methodologies/domain-driven-design',\n  inputs: {\n    projectName: 'E-Commerce Platform',\n    phase: 'tactical',\n    existingDomainModel: './artifacts/ddd/strategic-design.json'\n  }\n});\n```\n\n## Input Parameters\n\n| Parameter | Type | Required | Default | Description |\n|-----------|------|----------|---------|-------------|\n| `projectName` | string | Yes | - | Name of the project/domain |\n| `domainDescription` | string | No | '' | High-level description of the business domain |\n| `complexity` | string | No | 'moderate' | Domain complexity: 'simple', 'moderate', 'complex' |\n| `phase` | string | No | 'full' | Starting phase: 'strategic', 'tactical', 'full' |\n| `existingDomainModel` | string | No | null | Path to existing domain model (for refinement) |\n| `generateImplementation` | boolean | No | true | Generate implementation plans |\n\n## Output Artifacts\n\nThe process generates comprehensive DDD artifacts:\n\n### Strategic Design\n- `artifacts/ddd/SUBDOMAINS.md` - Subdomain classification and analysis\n- `artifacts/ddd/BOUNDED_CONTEXTS.md` - Bounded context definitions\n- `artifacts/ddd/CONTEXT_MAP.md` - Context map with integration patterns\n- `artifacts/ddd/context-relationships.json` - Machine-readable relationships\n\n### Tactical Design\n- `artifacts/ddd/TACTICAL_DESIGN.md` - Complete tactical design\n- `artifacts/ddd/domain-model.json` - Entities, VOs, Aggregates, Services\n- `artifacts/ddd/aggregates.md` - Detailed aggregate designs\n\n### Domain Events\n- `artifacts/ddd/DOMAIN_EVENTS.md` - Domain event catalog\n- `artifacts/ddd/event-flow.json` - Event flow diagram\n- `artifacts/ddd/event-handlers.md` - Event handler specifications\n\n### Language & Implementation\n- `artifacts/ddd/UBIQUITOUS_LANGUAGE.md` - Glossary of domain terms\n- `artifacts/ddd/IMPLEMENTATION_PLAN.md` - Implementation guidelines\n- `artifacts/ddd/module-structure.json` - Module and package structure\n- `artifacts/ddd/api-boundaries.md` - API and boundary definitions\n\n### Validation\n- `artifacts/ddd/DDD_SUMMARY.md` - Complete DDD model summary\n- `artifacts/ddd/LANGUAGE_ISSUES.md` - Language consistency report\n\n## Return Value\n\n```javascript\n{\n  success: boolean,\n  projectName: string,\n  complexity: string,\n  phase: string,\n  strategicDesign: {\n    subdomains: { ... },\n    boundedContexts: { ... },\n    contextMap: { ... }\n  },\n  tacticalDesign: {\n    contexts: [ ... ]\n  },\n  ubiquitousLanguage: { ... },\n  domainEvents: {\n    events: [ ... ],\n    handlers: [ ... ],\n    eventualConsistency: [ ... ]\n  },\n  implementation: {\n    plans: [ ... ]\n  },\n  validation: { ... },\n  artifacts: { ... },\n  metadata: { ... }\n}\n```\n\n## Integration with Other Methodologies\n\n### With Event Storming\nUse Event Storming to discover domain events, then feed into DDD for strategic and tactical design.\n\n### With Spec-Driven Development\nDDD provides the domain model, Spec-Kit provides the implementation execution plan.\n\n### With BDD/Specification by Example\nUse ubiquitous language in Gherkin scenarios to ensure specifications match domain language.\n\n### With Microservices Architecture\nBounded contexts naturally map to microservice boundaries.\n\n## Context Mapping Patterns\n\nThe process identifies and documents these integration patterns:\n\n- **Shared Kernel**: Two contexts share a subset of the model\n- **Customer/Supplier**: Downstream depends on upstream\n- **Conformist**: Downstream conforms to upstream model\n- **Anti-Corruption Layer**: Downstream protects itself from upstream changes\n- **Open Host Service**: Upstream provides well-defined service interface\n- **Published Language**: Shared language for integration (events, APIs)\n- **Separate Ways**: No integration needed\n- **Partnership**: Teams work together on integration\n\n## Best Practices\n\n### Strategic Design\n1. Start with subdomain identification - understand what's core vs supporting\n2. Invest heavily in core domains, less in supporting, use off-the-shelf for generic\n3. Define bounded contexts around team boundaries (Conway's Law)\n4. Be explicit about context relationships and integration patterns\n5. Keep ubiquitous language glossaries updated\n\n### Tactical Design\n1. Keep aggregates small - large aggregates cause performance and maintenance issues\n2. Use ID references between aggregates, not object references\n3. Make value objects immutable\n4. One repository per aggregate root\n5. Domain events for cross-aggregate consistency\n6. Avoid anemic domain models - put behavior with data\n\n### Ubiquitous Language\n1. Use domain expert language, not technical jargon\n2. If you can't explain it in domain terms, you don't understand it yet\n3. Update code immediately when language changes\n4. Use same terms in code, docs, conversations, and specs\n5. Different terms in different contexts is OK - that's why we have bounded contexts\n\n### Implementation\n1. Model contexts as separate modules/services\n2. Use anti-corruption layers when integrating with legacy systems\n3. Event-driven communication for loose coupling\n4. CQRS for complex read models\n5. Test domain logic in isolation from infrastructure\n\n## Example: E-Commerce Platform\n\n### Subdomains Identified\n- **Core**: Product Catalog, Order Management, Pricing\n- **Supporting**: Shipping, Notifications, Customer Support\n- **Generic**: Authentication, Payment Processing (Stripe)\n\n### Bounded Contexts\n- **Catalog Context**: Product information, categories, search\n- **Sales Context**: Shopping cart, orders, checkout\n- **Fulfillment Context**: Inventory, shipping, delivery\n- **Customer Context**: User profiles, preferences, history\n\n### Context Map\n- Catalog → Sales: Open Host Service (product API)\n- Sales → Fulfillment: Customer/Supplier (order fulfillment)\n- Sales → Payment Gateway: Anti-Corruption Layer (protect from Stripe changes)\n\n### Key Aggregates\n- **Product** (Catalog): ProductId, Name, Price, Inventory\n- **Order** (Sales): OrderId, LineItems, Total, Status\n- **Shipment** (Fulfillment): ShipmentId, OrderId, TrackingNumber\n\n### Domain Events\n- `ProductAddedToCatalog`\n- `OrderPlaced`\n- `OrderShipped`\n- `PaymentProcessed`\n\n## References\n\n### Books\n- **Domain-Driven Design** by Eric Evans (2003) - The original blue book\n- **Implementing Domain-Driven Design** by Vaughn Vernon (2013) - Practical implementation guide\n- **Learning Domain-Driven Design** by Vlad Khononov (2021) - Modern approach\n\n### Online Resources\n- [Domain Language (Eric Evans)](https://www.domainlanguage.com/ddd/)\n- [DDD Community](https://github.com/ddd-crew)\n- [Microsoft's DDD for Microservices](https://learn.microsoft.com/en-us/azure/architecture/microservices/model/tactical-ddd)\n- [Martin Fowler's DDD](https://martinfowler.com/tags/domain%20driven%20design.html)\n\n### Tools\n- [Context Mapper](https://contextmapper.org/) - DSL for context mapping\n- [Event Storming](https://www.eventstorming.com/) - Collaborative domain discovery\n- [Miro DDD Templates](https://miro.com/templates/domain-driven-design/)\n\n## License\n\nPart of the Babysitter SDK Methodology Collection.\n\n## Contributing\n\nTo enhance this methodology:\n1. Add new task definitions in `tasks/` directory\n2. Create example scenarios in `examples/` directory\n3. Update this README with new patterns and practices\n4. Submit pull request with detailed description\n\n---\n\n**Version**: 1.0.0\n**Last Updated**: 2026-01-23\n**Methodology**: Domain-Driven Design\n**Framework**: Babysitter SDK\n",
    "documents": [
      "specialization:domain-driven-design"
    ]
  },
  "outgoingEdges": [
    {
      "from": "page:library-domain-driven-design",
      "to": "specialization:domain-driven-design",
      "kind": "documents"
    }
  ],
  "incomingEdges": [
    {
      "from": "page:index",
      "to": "page:library-domain-driven-design",
      "kind": "contains_page"
    }
  ]
}