On each sticky note write the name of a domain object. That in itself should get the conversation started. Once you agree on a valid object and align on a name, stick it on the big sheet of paper. Don’t worry—this decision isn’t final. You’re going to move a lot of things around before you’re finished.

Repeat for every domain object. Don’t worry where you stick them on the paper right now. You’ll be doing a lot of repositioning as you figure out how things fit together.

As you place each object, discuss what it is and how it relates to other objects. Do you have the right object name? If not, toss the note and write a new one. Sticky notes are cheap.

Once you have your objects down, move them around to place related objects together. It doesn’t have to be perfect. Most first-draft domain models are messy. Move things around and talk about them. You might find you need an extra object or realize an existing object is unnecessary. The sticky notes and wastepaper basket are your friends.

Got a bunch of objects down on paper? Great! Now for the part that seems to scare people. Honestly, we’ve done this exercise in workshops and seen folks put off this step for as long as they can. Take a pen, and draw a line on the paper to connect two of the domain objects. Then write on the line a label to describe the relationship. Remember that sometimes those relationships aren’t thrilling (Recipe – hasIngredient – Ingredient), but label them anyway.

Keep going, connecting all your domain objects. After the commitment-free ease of sticky notes, drawing black lines with a Sharpie feels horribly permanent. It’s okay—this is still your rough, throwaway draft. It’s meant to be messy. Mistakes can even be helpful, signaling some bit of domain complexity to tease out.

Once you’re done, test-drive the model with different instance examples. Make sure everything holds up. Where you need a little tuning, make some quick fixes with the sticky notes.

Keeping everything on paper helps the exercise feel interactive. Sometimes we just think better about this stuff when we’re using our hands and moving around. Keeping it rough stops things from feeling too technical or intimidating (Figure 5.6). It gives everyone permission to make mistakes. Above all, this process is a way of helping the team come together and explore the domain. The conversations that come from modeling are as least as important as the model itself. It’s the activity, not the artifact, that matters most.

Agreeing on Your Domain

We often run workshops to help people get the hang of domain modeling. ­Usually we ask teams to pick their own subject. Once a team chose to model the TV show Twin Peaks. They started well, defining objects like Character and Episode. Then things started getting complicated. Should they model “inside” the universe (characters, interactions, motivations, places, and plot events) or “outside” the universe (episodes, broadcasts, movies, and DVD releases)? It quickly became as convoluted as the show itself.

Sometimes your team’s mental models need alignment. Understand and agree about up front exactly what you’re trying to capture. Modeling Health Care would take you in a different direction than modeling Medicine. Without team alignment on the domain, you’ll find it hard to express the domain as a model. If you’re having a lot of disagreements while modeling, wind things back. Make sure you all have the same domain in mind.

Discuss the subject domain your business operates in. If you sell concert tickets, serve your audience by modeling Live Music. If you work on a savings app, maybe it’s Personal Finance. Set that expectation early on. There’s a huge difference between modeling Live Music and attempting Music as a whole. Remember that your audience’s interest doesn’t begin and end with your business proposition. They’re interacting with your business because of their interest in a broader topic. Just what is that topic? And how can you better serve them by supporting it?

Consider what’s actually useful to your audience. If we modeled Road Tripping, we’d stick to Routes, Cities, Vehicles, and Points of Interest, and not so much the Interstate Highway Act, road composition, or gas
consumption. But your mileage may vary.

Modeling resists constraint because all knowledge is fundamentally connected. In our Road Tripping example, it would be easy and reasonable to throw in the ­Vehicle object. That might have a Vehicle Type. Pretty soon you’re down a rabbit hole, throwing in objects like Manufacturer, Engine, and Model Variant. This has drifted into the domain of Automobiles and lost sight of what’s most compelling to the audience and business.

Making Good Domain Objects

Our chosen subject contains abstract concepts we captured as domain objects. But knowing what makes a good object can be tough. So here’s a spoiler for the next chapter: Domain objects contain attributes. They are the atoms in the molecule, the protons in the atom, or something. (Don’t ask us to model Chemistry.)

For example, Person is a great object for our IA Summit domain. But we want our person to have a name, a headshot photo, a biography, and maybe even a link to their blog. Are these things also domain objects? Not necessarily. Most likely they’re just descriptive attributes of that domain object. These attributes don’t have to appear in your domain model. You’ll express them later in the detailed content model, which is explained in Chapter 6.

Figuring out what’s a domain object and what’s just an attribute can get tricky. There’s no “correct” answer here. It depends on how you choose to represent your domain.

Domain objects represent rich concepts that break down into attributes. Don’t include attributes in the domain model. If they come up in group discussion, by all means capture those decisions for later. You’ll be using them soon. But leaving them out of this model makes the diagram easier to read and less subject to change. It also helps keep your thinking at a high level. But hey, if some attributes end up expressed as full objects, it’s not a problem. It may even signal some future requirements you’ve yet to explore.

Finding a Ubiquitous Language

As a team you’re going to spend a long time referring to the same things. Meetings. Design and code reviews. Usability testing sessions. Over and over you’ll talk about the same domain objects. You need a common vocabulary—what domain-driven designers call a ubiquitous language.

This is nothing more than agreement on how everything’s named and defined, though agreement on language isn’t always straightforward. Teams can lose sight of their audience and skew toward technical or domain-specific jargon. Terms should make sense to everyone on the team, but also to the domain experts and users. The names of domain objects and relationship values should come from your research.

If you’re struggling to give something a clear name, it could be that your concept isn’t well-defined. Once, when working on a model for a music service, we debated whether to name a concept “account” or “profile.” It turns out we’d mangled a couple of concepts and our one domain object needed to be two.

Use consistent terms across database table names, CSS classes, and style guides. Your terms should be clear and self-explanatory enough to use even as navigation labels in your interface. Insist in meetings that everyone stick to the correct terms. It’s not unusual for engineers to fall back to technical jargon that feels more familiar. But listen for terms that just refuse to stick. It might be that the term chosen doesn’t reflect the concept it’s meant to describe. In that case, revisit the model and make sure your original understanding still holds. It’s fine to make changes—just make sure your model and your terms are in sync. A ubiquitous language helps keep your project team on the same page. If it isn’t spoken, it isn’t alive. Your goal is consistency through code, content, and user interface design. Make your ubiquitous language part of your everyday project conversation.

Establishing Cardinality

So far you’ve used a simple connecting line to show a relationship between two domain objects. Nothing simpler than good ol’ boxes and arrows. But what if those relationships come with strings attached? Sooner or later you’ll need to express some ground rules about how things connect.

Cardinality is counting how many of something can relate to something else. A car has only one engine. A person has at least one name but could have more. A dish has many ingredients. A musician may be part of zero, one, or many bands. That’s cardinality at work. You express it using crow’s foot notation (though other fine notation formats are available). Let’s look at the three main types of relationships.

One-to-One (1:1)

In a 1:1 relationship, one instance of one object relates to only one instance of another object. A specific key opens only a specific lock (Figure 5.7). And that specific lock can be opened only by a specific key. A specific Social Security number is assigned to a specific person. That person is assigned only that number. In practice, true one-to-one relationships are rare. If you encounter one, ask yourself whether both concepts are true domain objects. It may be that one is merely an attribute of the other.

One-to-Many (1:n)

In a 1:n relationship, an instance of an object can relate to several instances of another object. A sports team has many players, but they all belong to only that team (Figure 5.8). A session has one venue, but that venue probably hosts several sessions. Charles Dickens wrote a bunch of great books, but each book was written only by Charles Dickens. Great Expectations was published in many different editions, but they’re all editions of the same book. Charles ­Dickens kept many chickens, but each chicken had only one owner. One-to-many relationships are the most common type you’ll encounter.

Many-to-Many (m:n)

Is it getting crowded in here? In an m:n relationship, several instances of an object relate to several instances of another. At first glance, this might seem to happen all the time. Take that Book and Author example from before—some books (like this one) have more than one author. So it looks correct to say that several authors can write several books (Figure 5.9). But that becomes complicated. Your average relational database would have a meltdown. In fact, true many-to-many relationships are rare. If you find yourself faced with one, it’s a reasonable bet that you’re missing a domain object. This bit is important, so let’s elaborate.

On first inspection, it seems possible that Author to Book should be an
m:n relationship (Figure 5.10).

An author can write one or more books.

A book can have one or more authors.

For the model to inform the database design, you must resolve the m:n relationship into two 1:n relationships. You can do this by moving a few things around and creating a whole new domain object.

First, instead of Author as an object, try Person. After all, authorship alone doesn’t define a person. And maybe you’ll want to reuse a Person object from another domain.

Now create that new object. Call this the Collaboration. This object acts as a junction between Person and Book and defines the lineup of people (Strunk and White, Carrie and Mike, James Patterson and whoever . . .) who wrote a specific book. Now you can say:

One person can be part of one or more collaborations.

One collaboration can write one or more books.

And voila! The m:n becomes two 1:n relationships (Figure 5.11). Who knows, that Collaboration object could be valuable in itself. It’s like the difference between shouting out a bunch of songs and defining a playlist.

The catch here is that now a person has to be associated with a book via the collaboration, even when they’re only collaborating with themselves. For that reason, maybe Collaboration isn’t the best name, but we couldn’t think of a better one. Can you?

Optional Relationships

Charles Dickens may have many pet chickens, but ironically, poor old Roald Dahl has no chickens at all. So a person may have zero, one, or more than one pet. In crow’s foot, you can make a 1:1 or 1:n relationship optional by adding a circle to represent the zero (Figure 5.12).

Recursion

A recursive relationship connects a domain object to itself. Let’s take a ­classic workplace example. One or more employees are managed by a manager. ­Simple enough, right?

But hold on, isn’t that manager also managed by someone? And that someone is in turn managed by someone else? And really, is a manager a different class of person than an employee? (Hey, c’mon now. Be nice.) We could tidy this up by saying that an Employee manages zero, one, or many employees (Figure 5.13). It’s a recursion all the way up to the head honcho on the 40th floor. And even she’s an employee.

Don’t take offense when you hear people refer to this notation as a “pig’s ear.” They’re not critiquing your work.

Adding cardinality to a domain model is a pro move. It’s fine detail and not something you’d always include in the first draft, but it provides the important business logic you’ll soon need to move from paper to data.

Knowing When to Stop

You know that time when you meant to tidy a few loose papers and before you know it you’ve cleaned the whole house? Yeah, us neither—but modeling can be like that. Knowledge is sprawling and unordered. It can be hard to focus on one piece without following the rabbit hole to anything and everything else.

Chunk Your Model

One tactic is to assign ownership of parts of the model to different people on the team. It’s a little like working on a jigsaw puzzle as a group, as each person builds out a subsection. This helps them focus on one part of the problem. Regroup often as a team to compare your pieces and make sure they fit together. Working this way builds peer review into the process and exposes differences in understanding. It’s easier to update small parts of the model independently than to update the entire thing at once. Indeed, some parts may need more iteration than others. Just make sure you keep checking in as a team and sharing your progress.

Find the Boundary Objects

Often, you’ll define an object that could also belong to different subject domains. Take Song from the earlier example of Live Music. That object could be equally at home in the domain Recorded Music. (Though is a live version of a song truly the same thing as the recorded version? Maybe you’d need to throw a Version or Performance object in there.) These are boundary objects, because they mark the gateway to adjacent domains. When you come across one, be careful to stay focused on your original domain. It’s easy to wander off-course and start modeling out the entire universe.

Maintain distinct domain models for the different subjects you want to cover. That’s so much easier to manage than a one-model-to-rule-them-all approach. Boundary objects are your magic portals from one subject to the next. The BBC once modeled out all the TV shows they broadcast, episode by episode—right down to the songs featured in the track list. A show such as Mad Men is full of cool 1960s music. The BBC’s page for each episode listed every song heard, along with the original recording artist. In the underlying model, Song and Artist were boundary objects also used by the BBC Music service (with its own domain model). That made some magic possible. Bob Dylan’s entry in the Mad Men tracklist linked automatically to the Bob Dylan page on BBC Music. By connecting TV to Music through boundary objects, they opened up new user journeys. People could look up a song they heard on TV and follow a tight connection to the heart of the artist and their music.

Bringing In Experts

During your initial research, you made some new friends of the experts and enthusiasts. In an ideal world, you’d make them part of the modeling crew. They’d sit in on all your meetings and help you thrash it all out. In practice, this is rarely practical. So here’s a couple of ways to make sure your modeling has an expert’s seal of approval.

Bring Experts In Early

Domain modeling doesn’t have to come after meeting with subject-matter experts and users. As mentioned in the last chapter, it’s just as good (maybe even better) to start sketching the model while you have them. This can clarify the points they bring up in conversation; such is the power of visual thinking.

Collaboration works best while the model still looks rough. Sketches and sticky notes beat a slick diagram that’s printed out or, worse, displayed on a computer screen. You have a bunch of boxes and arrows that may not have the right labels, may not be complete, and may need connecting. Make everything easy to erase or reposition. Modeling is messy. People engage more when they can get hands-on.

However you choose to involve them, schedule regular check-ins with your experts, users, and stakeholders. Anyone should be able to follow the model and so understand your take on the subject. It’s a great conversation piece.

We’ve always found that when we get deep into modeling we start to see our subject as a series of interlocking parts. But don’t assume that even an expert thinks in the same way. Their mental model is probably rooted in practical examples, not abstract concepts and relationships. Be ready to help them to think at a higher altitude.

Bring the Experts Back

As you model, questions will come up, usually around the difference between two domain objects or the possible connections between them. Should you connect the Chef object to the Dish object? Or is it the Recipe object? Maybe both? This is the time to go back to the experts.

If your SMEs are also your project stakeholders, then it’s double brownie points. You’re bringing them into the design process, where their expertise is the most influential. It sure beats asking them to judge an art show of wireframes.

Who Uses the Model?

Together your team filled journals with interview notes. Your wastepaper basket brimmed with collective attempts to understand and sketch out relationships. You spent hours over pizza, debating what to call the things within your domain. How to define them. How they fit together. The team has soaked up enough domain knowledge that you could chat to a stranger in a bar and pass for experts yourselves. And to crown all that study, you arrived at a domain model so elegant and so simple (yet powerful) that any one of you could draw it on a whiteboard and discuss the finer details of your specialist subject. Go team!

Soon you’ll all start to show your superpowers. Content design. Interface design. Database and CMS design. These steps should be collaborative too. But even when you can’t work together, you’ll always have the domain model. It’s now your common reference point to guide each discipline.

Who will use this marvel and how?

Interface Design and Engineering

You’re going to design and build the interfaces that connect people to content. These windows into the world represent the content resources first described as domain objects. Through interface design and navigation, you’ll show how these resources fit together. Flip to Chapter 9, where we go deep on this.

Back-End Engineering

If you’re a back-end engineer, we bet you’ll see a domain model and start thinking of database tables. You’re no stranger to entity relationship modeling. This looks pretty much like the process you’d go through anyway. You’ve been able to help your team see the world as objects and relationships. Most content management systems (whether off the shelf or home-grown) run from a relational database. Design this database to map to the research-validated model. More of that coming in Chapter 8.

Content Strategy

For you folks working on the content itself, the domain model is a treasure map! It’s a record of the kinds of content your general and expert audiences have told you they’re interested in. You’ll use it as reference to audit the content you have and make a plan for the content you need. Intrigued? Chapter 7 is your jam.

More Examples

Yeah, we know. Our IA Summit domain example may be helpful, but it’s not the whole meatball. People ask us all the time for more examples to help cement the idea. Try these on for size:

Theme Parks

Mike is crazy-obsessed with Disney theme parks. Modeling it made him think hard about what a theme park even is (Figure 5.14).

Walt Disney World is a Resort, with a Location of Orlando, Florida.

Each resort has Parks, such as the Magic Kingdom or Epcot.

Each Park divides into Lands (Adventureland, Fantasyland). Each Land has Attractions (like Mike’s favorite, the Haunted Mansion). There are also Hotels. These sometimes have a direct relationship to a Park (such as Animal Kingdom Lodge) and sometimes don’t (Disney Pop Century).

Ooh, and each park also has a Weenie—Disney’s term for a big piece of architecture used to help in wayfinding. In the Magic Kingdom, it’s the castle. In Epcot, it’s the big geodesic ball.

Each attraction has one lead designer (an Imagineer like Marty Sklar or Mary Blair). In practice, it would be difficult to credit everyone who worked on an attraction, so “lead” designer is sufficient. Also this avoids having to resolve the many-to-many relationship between designers and attractions. Attractions could be based on some prior creative work (as with Jules Verne’s 20,000 Leagues Under the Sea).

Each park has a Restaurant or six, as do the hotels. Each restaurant has Meal Events (Cinderella’s Royal Table, anyone?), and those meals are usually associated with a specific Character. That character (we’re looking at you, Pooh) may themselves be based on a prior creative work.

It’s not a complex model (it’s a small world after all) but one that tries to capture what’s useful and interesting. It’s reusable for any Disney resort and may even be suitable for any theme park anywhere.

Restaurants

From all the references to the BBC, you may well think our approach is only for big content publishers. What if you just want to make a website for your restaurant (Figure 5.15)? Let’s give it a try.

Every decent restaurant prides itself on the food. Each Dish is the plate of food served up (anything from lapsang souchong tea–smoked salmon to truffled mac-n-cheese).

Each Dish might be created by a particular Chef, adding a certain je ne sais quoi (usually to the price). A Dish gets served as a particular Course, so we know our starters from our desserts. And a Dish will likely have origins in a specific Cuisine (from French to Tex-Mex).

The Dish consists of Ingredients, important information for customers with food allergies. Speaking of which, Dishes may or may not be appropriate for a particular Diet (for example, kosher, halal, and celiac).

These days it’s popular to list a Supplier to give the ingredients some provenance. It’s not just a burger; it’s a Happy Cow Farm grass-fed Angus burger.

We curate a set of Dishes (and courses) in a Menu. Choosing dishes for a menu is a fine art for the restaurateur. Many restaurants will have more than one menu available and may even rotate the menu daily.

Each dish on the menu could be paired with a Wine. Guess what—boundary object alert! Wine is of course a whole other domain that would be modeled separately and then linked to customers from the world of food to the broader world of wine.

Okay, admittedly this sounds like quite a fancy restaurant. And we’ve concentrated on the culinary aspect of the experience. But it pays to keep things focused on the concepts people find most delicious. Food for thought.

Live Music

A favorite example of ours is the world of live music concerts (Figure 5.16), not least because it contains some unpredictability we can account for.

An Act is our term for either a solo artist or a group. If you or more likely your parents, have seen, Fleetwood Mac or the Drifters over the years, you know that “group” can be a fluid term. So for completeness’ sake, perhaps you want to document the Lineup of a specific act.

This is the unpredictability we mentioned. An individual Performer is part of the Lineup rather than part of the Act. Take That are still Take That, regardless of whether Robbie Williams joins one night.

A Performance is a single gig on a single date. Though maybe the ­hardest-working acts in show business give more than one performance each day.

Of course you care about each Song in the performance. (By the way, there’s another possible boundary object.) But you also want to know which songs were in the Setlist for a given performance. Believe it or not, there are true fans out there who log this stuff.

A Venue (Madison Square Garden, Ronnie Scott’s Jazz Club) holds a performance. Each performance can be part of a Tour, covering many venues across many Locations.

Finally, each performance, or an entire tour, could be in a certain Genre. ­Musical genre is another boundary object. It connects the gig to a bigger canvas of similar music, past and present. It also helps avoid Dylan’s weird bluegrass stuff.

And you’re done. She’s a model, and she’s looking good.

As with all these examples, take them and play with them. Run through examples. Look for any instances that would change how the model works. Add or remove objects and relationships until they work for you.

Modeling for the Future

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. Because as hard as it may be to swallow, no one cares about your content. They care about what they care about. Fine wine. Waterskiing. Himalayan travel. And all the points of interest within those topics. When you can map your content to those things, you stay focused on serving their needs. And then maybe they do start to care a little about your content, or at least recognize a kindred passion.

During your research, you’ll definitely want to figure out underlying user needs and pain points. That’s all in day’s work for your average UX designer. But take the time to understand and respect the subject domain itself. That domain has its own structure, rules, and quirks. It shows everyone the real things that your audience cares about.

The model sets you up for the future. Use it to plan the content needed to serve the subject. Use it to uncover gaps in your inventory. Use it to determine which content makes the cut. Use it to guide the natural navigation of your product. Mapping content to concepts helps maintain structural integrity as your inventory scales. Whether you have a few dozen content resources or a few thousand, relationships between them remain the same. Don’t feel pressured to represent the entire domain with content, at least not all at once. You’re
free to choose which parts of the model you’ll expose in your interface designs. Remember, this isn’t a site map.

Content changes often. Every good content strategist will tell you to keep it fresh. To a lesser degree, interfaces are subject to change. We update our visual identity. Change our layouts. Build whole new interfaces for emerging technology. But beneath all the content and UI lies the truth of what they represent. Of course, we can’t claim that the domain itself never changes. New knowledge has increased our understanding of everything from astronomy to zoology. Yet as we dive from the surface of publishing and presentation to the depths of domain, change happens less.

Regardless of what you publish, or how often, follow the advice of your experts and users. Surface the meaningful relationships that give form to a subject. Everything you build is just a digital representation of something real. Understanding that reality should be where any design starts. Our content is just a means to someone’s end.