‘The domain model maps the world of your chosen subject. It doesn’t care which interfaces you’ll build. It doesn’t care what content you have. It models what your content will be about.’ p. 91
The above, ‘what your content will be about’
‘A domain model is a formal representation of the concepts that are important to how an organization communicates and operates in a given domain. The modeling process identifies and defines key concepts, and describes the consistent, predictable relationships between concepts in the domain.’
Also see Organic navigation, ,and
‘“Storytelling” might have become a design cliché, but stories and anecdotes are still the best vehicles for informal knowledge exchange’ From an interview with Michael Smethurst, p. 93
Model the domain first, then the content based on the domain model. Try to make the domain model cover as many knowledge cases of the domain as your subject-matter experts can help you map out.
But as Hane and Atherton repeats: be wary of boundary objects. These are the objects that take you domain into a different one. Say your domain model is about food, a dish might have a wine pairing. You’re modelling food, not wine, so be careful, and stick to your domain. Rabbit holes are often deep and unwieldy.
Only branch into a new domain where needed, and remember that you need to start the process over again for that domain. And link the domains together using the boundary object, in this example: wine pairing.
You don’t have to include all of the domain model in your content model. Maybe some domain objects are irrelevant for your organisation or you won’t have content for that part of the domain for a while.
‘In software engineering, a domain model is a conceptual model of the domain that incorporates both behavior and data.In ontology engineering, a domain model is a formal representation of a knowledge domain with concepts, roles, datatypes, individuals, and rules, typically grounded in a description logic.’