Comparison

OCOM vs Domain-Driven Design

Executive 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

Not compared

  • DDD's tactical patterns (Repository, Factory, Specification pattern)
  • Specific implementation frameworks or languages
  • Event sourcing or CQRS as architectural choices

Terminology mapping

OCOMDDDEquivalent
ObjectAggregatePartial
Core VocabularyUbiquitous LanguagePartial
DomainBounded ContextPartial
EventDomain EventPartial
Repository (pattern)None

Conceptual differences

AspectOCOMDDD
Centre of gravityObject-centric: what the organization governsContext-centric: how one system's code is structured
TimeObject state over the whole lifecycleAggregate consistency within a transaction
GovernanceFirst-class: ownership, policy, constraintContext maps govern model boundaries and team ownership, not operational accountability
ScopeSpans systems and technologiesBounded to one model and language boundary (a bounded context)

Concept coverage

ConceptOCOMDDD
Software design guidanceOut of scopeCovered
Object identityCoveredPartial
LifecycleCoveredPartial
GovernancePartialOut of scope
OwnershipCoveredPartial
EvidencePartialOut of scope
AI retrievalPartialOut of scope

Three OCOM cells read Partial rather than Covered (Governance, Evidence, AI retrieval), and the reason for each is recorded in the specification's own register: Governance is a Core Characteristic of every Object that no document defines as one (AO-023); Evidence has no Meta, Models or Language definition, its Definition being reserved for a future version (AO-021); AI retrieval is disclaimed by AI/Context/Context Assembly.md, which prescribes no retrieval algorithms (AO-048). Workflow and Event are defined normatively at the Models tier and carry no Core Vocabulary term record.

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.

Interoperability

References