Domain Model¶
Artifact — instantiates Ontology Clarification
Represents the clarified entities, categories, relations, and constraints of a problem domain in a form that teams can inspect and use.
A Domain Model is the technology-neutral picture of what a problem domain contains — its entities and their states, the categories that group them, and the relations that connect them — written in language the whole team shares, deliberately before any decision about how it will be stored or coded. Its defining trait is that it belongs to the domain, not to a system: it is the single conceptual reference that a database, an API, a policy document, and a team's everyday speech all trace back to. Where a wall sketch tolerates ambiguity, a domain model insists that each entity, each category boundary, and each relation be named precisely enough that a domain expert and an engineer, reading it, mean exactly the same thing. It is the ontology turned into a durable, inspectable object teams can build on — the shared map, not yet the machine.
Example¶
An insurance company is launching a new product line and keeps shipping features whose builders quietly disagree about what a policy even is. To one team it is the signed contract; to another it is the coverage in force this month; to a third it is a row in the billing system. Before writing more code, a modeler sits with underwriters, claims adjusters, and actuaries and draws the domain model. They inventory the entities — Policy, Insured, Coverage, Claim, Premium, Beneficiary — and pin down categories that had been blurred: Coverage splits into liability versus property; a Claim moves through the states reported → adjudicated → paid/denied. Then they name the relations exactly: a Policy grants one or more Coverages; a Claim is filed against a specific Coverage, not against the Policy as a whole; a Beneficiary receives a payout only on a covered claim.
Following the domain-driven design practice of building a shared model in a ubiquitous language,[1] the group insists every term on the diagram is a term everyone will use in meetings, tickets, and code. The output is not a database and not a slideshow — it is a conceptual model that the claims workflow, the rating engine, and the policy documents will each map back to. The argument about "what a policy is" stops recurring, because there is now one inspectable place where it was answered.
How it works¶
- Elicit entities from the experts, not the database. The candidate things and states come from the people who work the domain, so the model reflects the business rather than an existing schema's accidents.
- Fix category membership. Each grouping states what belongs, what does not, and why the distinction changes how someone acts.
- Name relations precisely. Links carry direction and multiplicity ("a Claim is filed against exactly one Coverage"), so the model says how things relate, not merely that they do.
- Stay technology-neutral and speak one language. No tables, no classes yet; the same vocabulary is used by business and engineering, which is what lets many implementations align to one model.
What distinguishes it from an operational schema is that it commits to meaning while deferring storage: it is the reference implementations conform to, not itself a running system.
Tuning parameters¶
- Ubiquitous-language strictness — enforcing one term per concept across speech, docs, and code keeps everyone aligned but is a constant editorial cost; loosening it is faster but lets synonyms reintroduce the drift.
- Granularity of clusters — modeling a few coarse aggregates keeps the picture legible; splitting into many fine entities captures nuance but multiplies the relations to maintain.
- Structure vs. behavior — a pure noun model (entities and relations) is quick; adding the invariants a valid state must satisfy is richer but heavier.
- Bounded scope — one focused model per context stays coherent; a single model spanning the whole enterprise looks complete but tends to buckle under contradictory local meanings.
When it helps, and when it misleads¶
Its strength is giving business and technical people one criticizable reference, so definitional drift is caught in a review rather than in production. It is the right instrument when several groups must build against the same understanding and a shared, inspectable conceptual map — not yet a schema — is what they lack.
Its failure mode is drifting from reality once it stops being maintained: a model that was true at launch quietly diverges as the domain changes, and a stale model is worse than none because people still trust it. The classic misuse is the big model up front — an elaborate, comprehensive diagram built once and then frozen, admired but no longer describing how the system behaves. The discipline that keeps it honest is to treat the model as living: bind it to the ubiquitous language people actually use, and revise it whenever a new distinction earns its keep rather than defending the original picture.
How it implements the components¶
A Domain Model fills the archetype's conceptual slots — the shared map, before any implementation:
entity_inventory— the enumerated entities and states the domain must recognize, drawn from the experts.category_definition— the categories that group those entities, each with explicit membership and a reason the distinction matters.relation_definition— the named, directed relations (with multiplicity) that connect entities and categories.
It does not encode the operational constraints and special-value handling that make a model runnable in software (boundary_condition, edge_case_register — that's Data Model), nor the machine-readable term provenance and cross-vocabulary mappings a reasoner needs (term_source_map, translation_crosswalk — that's Semantic Schema); and it records the reconciled result rather than running the reconciliation itself (assumption_reconciliation_record, ontology_revision_rule, evidence_anchor — that's the Ontology Review Workshop).
Related¶
- Instantiates: Ontology Clarification — the Domain Model is the durable conceptual map the clarification produces.
- Consumes: Ontology Review Workshop supplies the reconciled assumptions and agreed definitions the model records.
- Sibling mechanisms: Data Model · Semantic Schema · Ontology Review Workshop · Concept Map · Ontology Map · Taxonomy · Glossary
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Domain Model operates as a non-executable information artifact that externalizes static or prospective structure because it represents the clarified entities, categories, relations, and constraints of a problem domain in a form that teams can inspect and use.
Independent corroboration: The frozen evidence defines Domain Model as 'Represents the clarified entities, categories, relations, and constraints of a problem domain in a form that teams can inspect and use', so its operative form is Representation, Specification & Plan.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Multi-domain
Rationale: Software engineering, especially domain-driven design, cohered domain models and ubiquitous language as shared abstractions of entities, relations, and constraints.
Related originating lineages:
- Organizational & Management Science — Business analysis supplied conceptual models of processes, roles, rules, and organizational objects.
- Systems Thinking & Cybernetics — Systems modeling supplied broader relational representations of bounded problem environments.
Review resolution: Software engineering, especially domain-driven design, is primary; business analysis and systems modeling materially shaped the shared conceptual representation rather than merely applying it.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
A Domain Model is the conceptual member of an artifact family that is easy to conflate: it says what the domain means, a Data Model says how one system stores it, and a Semantic Schema says how a machine reasons over it. Keeping the domain model independent of storage is what lets a database migration or a knowledge-graph project change without renegotiating what the business believes exists.
References¶
[1] In Eric Evans's Domain-Driven Design (2003), the domain model is a rigorously selective abstraction of domain knowledge shared by developers and domain experts, expressed in a ubiquitous language used consistently across speech, documents, and code. registry ↩