A domain model describes the important concepts in an area of knowledge or activity, how they relate and which rules shape those relationships. It makes a team’s understanding explicit enough to discuss and test. In content work, it’s often a conceptual diagram with short definitions; in software design, the term can also refer to an implemented model that combines data and behaviour.
The model is selective, not an attempt to catalogue everything. Its scope follows the subject and purpose, rather than the organisation chart or the pages on an existing website. A model of a lending service, for example, might distinguish an item, a borrower and a loan, including the rule that one borrower can have several loans. The concepts and their names develop together through Ubiquitous language: agreeing a label can reveal that people haven’t agreed what the thing is.
Why it matters for content
A domain model gives content teams a way to understand their subject before deciding how to publish it. Separating a loan from the item being borrowed helps a team see that an item’s description and a borrower’s return deadline are different kinds of information. The distinction can inform public explanations, navigation and the records that supply them. Starting with existing pages can hide it, because several concepts may already be bundled into one page.
A Content model translates relevant parts of that understanding into publishable structures: content types, fields and relationships. The translation involves editorial choices. Some domain concepts need their own reusable records; others need only a field, an explanation or no published representation at all. A guidance article may explain several concepts without being a concept in the domain itself. There needn’t be one page, or even one content type, for every box in the diagram.
The Content Lexicon offers a related example. Its entries define concepts across content work, while links between terms make some connections visible. In that sense, it can be read as a partial, evolving model of the field – expressed through definitions and links rather than a formal diagram. It doesn’t attempt to map every concept, relationship or rule.
Modelling also exposes disagreements before a publishing system gives them permanent homes. Domain experts can test the model against real cases, while research with users can reveal distinctions or language the organisation has overlooked. Different services may need different models of the same subject. Their boundaries and connections matter more than forcing everything into a single organisation-wide diagram.
How AI changes the picture
An AI assistant can help turn interviews and source documents into a provisional set of concepts, suggest relationships and identify apparently conflicting definitions. That can give a team something concrete to challenge earlier in the work. Its suggestions still need testing against the domain: a plausible relationship isn’t evidence that the organisation operates that way, and an unusual case may reveal a missing concept rather than an error to tidy away.
Once agreed definitions and relationships are represented in usable source material or connected records, they can help an assistant interpret questions and find relevant information. It could distinguish a borrowing limit from a return deadline, for example, instead of treating everything about loans as interchangeable. The diagram alone doesn’t create that capability; the system needs access to the definitions, relevant records and a way to use their relationships. Where rules determine eligibility or other consequential decisions, implementing and validating those rules matters as well as explaining them.
Questions people ask
- Does “domain” mean a website address?
Here it means a subject or area of activity, such as lending, conservation or recruitment. A domain model can serve several websites, services and internal systems.
- Is a domain model the same as a taxonomy?
A taxonomy classifies things. A domain model can express wider relationships, such as who borrows an item and which loan records that borrowing. Classification may be part of the model, but doesn’t describe all its connections or rules.
- Does it have to become a database?
It can remain a shared conceptual model. It may inform a database schema or software design later, but storage choices aren’t its starting point. A database also needs implementation decisions that the conceptual model may leave open.
- How much detail is enough?
Enough to support the decisions it’s being used for. A small service may need a handful of concepts and relationships. More detail earns its place when it resolves an ambiguity, captures a consequential rule or helps explain a real case. Extra boxes don’t make a model more accurate.
Learn more
- Designing Connected Content – publisher’s sample – Mike Atherton and Carrie Hane introduce their subject-first approach to publishing. The sample includes an interview with Annette Priest about using domain and content modelling across a complex product portfolio.
- Domain Model – Martin Fowler’s concise definition of the software pattern, where interconnected objects represent the domain and combine behaviour with data. A useful distinction from a purely conceptual diagram.
- Bounded Context – Fowler explains why different parts of an organisation may need different models, with explicit relationships between them rather than a single universal account.