Because it’s evergreen, I find myself writing up another explanation of the distinctions between a Domain model, a Content model, and a Data model. For most folks this doesn’t matter, but for some teams, it’s a point of contention!
A “domain model” describes the different elements of a particular sphere of knowledge, or an activity, or what not. A business’s “domain model” covers the things it makes, the partners it interacts with, the processes it engages in, the people that participate in them, etc.
A company might use domain modeling to answer questions like: “What’s the relationship between our fulfillment process and our sales process?”
A good domain model will help a team understand of the various moving pieces in a project, an organization, an industry, an ecosystem. In the realm of digital comms and publishing, @carriehd and @MikeAtherton literally wrote the book on this: Designing Connected Content.
A content model is shaped by and affected by the domain, but it’s not the same thing. Broadly, content is stuff an organization produces to communicate with an audience. That content can be the product in question, it can be marketing materials…
…it can be support materials and guides and FAQs used to support a product or service. It can be messaging meant convince an audience of the importance of an idea. It’s broad, but it’s about an audience and an intended effect.
A content model captures things like, “When we’re selling, what things do we send?” or “To explain the news, what things do we make in order to contextualize a story?” Zooming in, it captures things like: “Does this need images? Do we care about authorship?” etc.
It has a direct relationship to the domain model! They often overlap, because domain items must often be explained, described, etc to audiences — and content items often imply domain processes to create, manage, distribute, etc
But! They’re not the same, because not everything in your domain model needs to be talked about, communicated, to an audience. It’s just the stuff you do. Or the way things work. And not all content is on the domain model. “Blog post vs Podcast?” might just not matter.
Finally there’s the data model. It’s a nuts-and-bolts view of how both content and critical business information gets stored. “How are we going to track how many widgets are in stock” has a big impact on the Domain and the Data, but is often irrelevant for the content model.
The data model often has fussy details, too, that don’t matter for the other models. Like the Domain/Content split, Content/Data has overlap but it’s not the same, and assuming they should correlate 1:1 is a mistake.
A content model might specific a “picture” and even say “pictures have captions, copyright information, and multiple resolutions” — the data model needs to worry about whether it’s storing the image as a database BLOB, a local pathname, a DAM asset key, etc.
Jesse nails the tricky part here; the concerns of all three of these are interlinked; a data model that deals with “inventory” is related to a content model that stores “product information” but there are often different concerns.
A data model might account for (say) outstanding orders, incoming stock, current stock on hand, and so on because all those things matter to the domain it serves…
but the content model might only care about the final number — “how many are in stock?” and “if there are less than 5, does my call to action change?”
So the ‘domain’ model, the ‘content’ model, and the ‘data’ model all have a concept of a product, but they’re concerned about different things. A content model describes stuff that is ultimately stored in a data model, but the details of that storage don’t necessarily matter.
In very simple scenarios, a lot of these distinctions are unnecessary complication. Adding an ‘in stock’ checkbox to a ‘product’ post type in the CMS might be good enough.
But at a larger scale, the tools and systems to support (say) product descriptions and promotional copy and customer quotes about a product are often very different than the ones to support (say) inventory and availability tracking and delivery projections.
So what you see on a web page in is often a mix of two very different systems — managed content, with additional bits of critical data piped in from other systems to inform logic (“should we show a CTA to induce people to buy, or direct them to a product that’s in stock”)
And, just to demonstrate how they’re all connected… the domain model might impact them both: if “descriptions of products” are supplied by vendors rather than written by a company’s own team, for example, they might live in the inventory system rather than the CMS…
…leading to confusion when editors can’t change or tweak something that’s conceptually part of the “content model” for their business’s communications.
It’s complicated — and the distinctions can be fuzzy sometimes! — but the temptation to collapse them to one ‘perfect model’ often leads to even more problems and confusing as important distinctions are erased.
Also, I am trying HARD not to make an elaborate trinitarianism joke.