Issue 46

Domain models aren’t content models

I realized recently that Model Thinking had a significant content gap, and I have hardly talked about something that has been a really helpful practice to me. I’ve mentioned it in only two issues, Issue 4 and Issue 33, so it’s high time we do a slightly deeper dive into domain modeling.

As AI forces more people to shift from thinking about words on webpages and more about how larger concepts relate to each other—and words like knowledge graphs and taxonomy and ontology get more common—I’m seeing more people talk about domain models.

I first learned about domain modeling in the book Designing Connected Content by Carrie Hane and Mike Atherton, and was instantly intrigued.

Domain models, in a nutshell

A domain model is a visualization of a specific real-world area (domain). Generally, a domain model has nodes connected by arrows that define a relationship.

Software engineers may be familiar with domain models, but most Model Thinking readers have content backgrounds, so a grammar-based explanation might be helpful.

Think of the nodes as nouns, usually objects or concepts and the arrows as verbs. As an example, let’s think of the domain of bicycles. There will be a lot of nouns and verbs in this domain, but let’s call out four nouns for now: manufacturer, model, bike, and terrain. When we start adding in verbs, we get: Bike has manufacturer, manufacturer makes model, model is optimized for terrain. We could go on, but we won’t.

Domain models are not content models

As you read this and look at the sample diagram, you may be thinking “That’s a content model.” It’s not, though, but explaining the difference is challenging.

I tend to think of the domain model as a more abstract, more fundamental than a content model. It’s saying “Here’s what exists in this domain,” not “Here’s the content we need in this domain.”

That said, I find domain models sometimes do yield direct insights into future content types or taxonomies.

Why do domain modeling

The primary reason to create a domain model is to align everyone working on your content project. The act of creating the domain model is one of asking questions, listening, asking more questions, and eventually creating a shared understanding.

Other reasons to create domain models include:

• Learning a new domain
• Finding gaps in understanding or focus
• Planning for the future

Obviously, there’s a lot more to domain models than this, but Designing Connected Content already exists, so I refer you to that if you want to learn more.

A cool domain modeling trick I just did last week

I’m working on a domain model for a project for myself (not a client project), and I wasn’t feeling entirely confident about it.

I had started on a whiteboard (easy to get the juices flowing that way) and then I moved that diagram into Miro. Then I thought it might be helpful to run the model through Claude with the context it has about my business, so I asked it what visual diagramming tools it could read easily, focusing not on interpreting an image but on reading the underlying data of the diagramming tool.

It turned out that Miro didn’t seem to have a friendly data structure, but the tool Excalidraw did, with a JSON structure at its core. I was able to recreate my diagram in Excalidraw, download the Excalidraw file, upload it to Claude, which very successfully read the objects and relationships.

Claude then was able to give me actionable feedback, accurately highlighting the areas of the diagram that were strong and the areas that were weak, as well as prompting me to provide more context to explain the model, reason through some questions I had, and even sparking ideas for new objects for me to add.

Designing Connected Content by Carrie Hane and Mike Atherton

Top of mind

• Best thing I read in the last 2 weeks: Speaking of … Hane wrote a recent LinkedIn post speaking metaphorically about how people want a clutter-free magazine-ready house when reality is a bit messier. Hiring a decorator won’t fix the clutter problem. Of course, the house is a website, clutter is content debt, and decorators are web design agencies. It’s a helpful metaphor that I might borrow.
• Something that made me smile in the last 2 weeks: In the last week, I had interactions with 3 people from two different parts of my history years ago. Both interactions were unexpected, and both left me with renewed spirits. One of the interactions will be a memory I will treasure for a lifetime.
• A pattern I noticed recently: This is a meta-pattern, if you will. Across the different facets of my life, pattern recognition is a sign of an increasingly senior role. Content designers, UX designers, and content strategists learn to recognize patterns and build their work on those patterns. Firefighters and EMTs learn algorithms to assess a scene, and there are patterns of things they are looking for. Same for consultants, who look for patterns that are triggers for their expertise and build other patterns that they can use to monetize their work. But the expert designers, strategists, firefighters, medics, and consultants are the ones who recognize when something doesn’t fit their expected patterns and use that as a warning sign or a cue to investigate further.

Welcome to the 1 new subscriber who joined us since the last issue of Model Thinking.