Skip to content

CONCEPT Cited by 1 source

Domain model

Definition

A domain model — in the data-integration / knowledge-graph sense Netflix UDA uses — is a controlled vocabulary that defines:

  • Classes of keyed entities (concepts with identity).
  • Attributes of those classes (typed properties).
  • Relationships between entities — keyed or nested, within the domain or across domains.
  • Taxonomies of types — classes organised into subtype hierarchies of arbitrary depth.

It's the formal conceptualisation of a business or system domain, authored once and treated as data — not as source code, not as documentation.

"Upper is a language for formally describing domains — business or system — and their concepts. These concepts are organized into domain models: controlled vocabularies that define classes of keyed entities, their attributes, and their relationships to other entities, which may be keyed or nested, within the same domain or across domains." — Netflix UDA post (sources/2025-06-14-netflix-model-once-represent-everywhere-uda)

Monotonic extension

Domain models are extensible monotonically — new attributes and relationships can be added from other domain models without retracting prior facts. The algebraic property that makes this safe is conservative extension.

Domain models as data

The distinguishing claim of UDA's framing: domain models are data, not code, not docs. Expressed as conceptual RDF and organised into named graphs, they are introspectable, queryable (SPARQL), versionable, and diff-able like any other graph data. This is the precondition for transpiling them into many target schemas (GraphQL / Avro / SQL / RDF / Java).

Business domain + system domain

UDA extends the term in two directions:

  • Business domain models — actor, movie, asset, and their relationships.
  • System domain models — the data systems themselves (GraphQL, Avro, Data Mesh, Mappings) modelled in the same language. A system's schema language + information architecture becomes a domain model, so that the same tooling (transpiler, projections, UI) works on both.

Distinction from DDD "domain model"

Domain-Driven Design (Evans, 2003) uses "domain model" to mean the object graph + invariants within a single bounded-context service codebase. UDA's "domain model" is broader: it is a conceptual, tool-agnostic, data-representable specification of a domain's classes + relationships that can drive multiple service implementations + schemas at once. The wiki uses UDA's framing when the concept is invoked in an integration / knowledge-graph / schema-transpilation context.

Seen in

Last updated · 319 distilled / 1,201 read