{
  "id": "COMP-DDD-001",
  "slug": "ddd",
  "status": "Informative Comparison",
  "subject": "OCOM",
  "target": "Domain-Driven Design",
  "targetShort": "DDD",
  "summary": "Domain-Driven Design is a software design discipline for building a system: bounded contexts, ubiquitous language, aggregates, and the conversations between domain experts and developers that shape code. OCOM agrees with DDD's core instincts, that language must be explicit and boundaries must be named, but disciplines a different layer. DDD disciplines how a team builds one system; a model built with OCOM disciplines what the organization knows to be true across all of them.",
  "scope": {
    "compared": [
      "Whether each governs one codebase or the organization's operational record",
      "How each treats identity and language across system boundaries",
      "Where each discipline's authority actually ends"
    ],
    "notCompared": [
      "DDD's tactical patterns (Repository, Factory, Specification pattern)",
      "Specific implementation frameworks or languages",
      "Event sourcing or CQRS as architectural choices"
    ]
  },
  "mappings": [
    {
      "ocom": "Object",
      "target": "Aggregate",
      "equivalent": "Partial"
    },
    {
      "ocom": "Core Vocabulary",
      "target": "Ubiquitous Language",
      "equivalent": "Partial"
    },
    {
      "ocom": "Domain",
      "target": "Bounded Context",
      "equivalent": "Partial"
    },
    {
      "ocom": "Event",
      "target": "Domain Event",
      "equivalent": "Partial"
    },
    {
      "ocom": "—",
      "target": "Repository (pattern)",
      "equivalent": "None"
    }
  ],
  "differences": [
    {
      "aspect": "Centre of gravity",
      "ocom": "Object-centric: what the organization governs",
      "target": "Context-centric: how one system's code is structured"
    },
    {
      "aspect": "Time",
      "ocom": "Object state over the whole lifecycle",
      "target": "Aggregate consistency within a transaction"
    },
    {
      "aspect": "Governance",
      "ocom": "First-class: ownership, policy, constraint",
      "target": "Context maps govern model boundaries and team ownership, not operational accountability"
    },
    {
      "aspect": "Scope",
      "ocom": "Spans systems and technologies",
      "target": "Bounded to one model and language boundary (a bounded context)"
    }
  ],
  "capabilities": [
    {
      "capability": "Software design guidance",
      "ocom": "Out of scope",
      "target": "Covered"
    },
    {
      "capability": "Object identity",
      "ocom": "Covered",
      "target": "Partial"
    },
    {
      "capability": "Lifecycle",
      "ocom": "Covered",
      "target": "Partial"
    },
    {
      "capability": "Governance",
      "ocom": "Partial",
      "target": "Out of scope"
    },
    {
      "capability": "Ownership",
      "ocom": "Covered",
      "target": "Partial"
    },
    {
      "capability": "Evidence",
      "ocom": "Partial",
      "target": "Out of scope"
    },
    {
      "capability": "AI retrieval",
      "ocom": "Partial",
      "target": "Out of scope"
    }
  ],
  "interoperability": [
    "A DDD bounded context can implement a slice of an OCOM model.",
    "OCOM identities give separate bounded contexts a shared anchor: the \"customer\" in two contexts keeps its own model in each, while resolving to one governed Identity."
  ],
  "references": [
    {
      "label": "OCOM Object",
      "url": "/vocabulary/object"
    },
    {
      "label": "OCOM Identity",
      "url": "/vocabulary/identity"
    },
    {
      "label": "OCOM Relationship",
      "url": "/vocabulary/relationship"
    },
    {
      "label": "Domain-Driven Design, Eric Evans (2003)",
      "url": null
    }
  ],
  "canonical": "https://ocom.uno/comparisons/ddd",
  "url": "https://ocom.uno/comparisons/ddd",
  "coverageScale": [
    "Covered",
    "Partial",
    "Out of scope"
  ],
  "coverageNote": "Covered: the model defines the concept explicitly. Partial: the concept appears indirectly or by convention. Out of scope: the model does not set out to describe it; a boundary, not a deficiency. Three OCOM cells read Partial rather than Covered because the specification's own register records the gap: Evidence (AO-021), Governance (AO-023) and AI retrieval (AO-048). Workflow and Event are defined normatively at the Models tier without a Core Vocabulary term record."
}