Home » Product Management » How to Build a Domain Model

How to Build a Domain Model

I have written frequently about what a domain model is and why it’s important to have one. Reading those posts would lead you to believe that it’s a simple task to build one. That’s not a wrong impression. The difficulty lies in getting started and then ensuring the model is based on fact, not opinion. Remember, your objective is an artifact that will help you define scope, prioritize your efforts, and provide a common vocabulary that allows for efficient communication in addition to a common understanding of the environment in which your product will operate. Let me walk you through a process that has worked well for Ten Mile Square.

wooden house frame with yellow forklift in front


Before you begin this process, you need to make sure your head is in the right space. This is an exercise in building a fact base drawn from your organization’s current operating environment and its goals. The domain model that results will provide for additional activities, which may well take into account opinions, but your position as the builder of this model should not involve expressing your opinion. This is, ultimately, a descriptive exercise, not a prescriptive one.

Additionally, you need to finely tune your spidey sense to be on the lookout for certain parts of speech. You will be collecting all of the nouns you can find that describe people, groups, and objects that operate in this universe, such as buyer, supplier, and product. You’ll also need to assemble the verbs that establish a relationship between/among two or more of the nouns you’ve collection. For example, a buyer purchases a product. Finally, while not absolutely necessary for the domain model, you will want to keep an eye out for adjectives and adverbs that describe potential non-functional requirements for future use.

Analyze Existing Documentation

Building a domain model is a time-consuming effort and one you cannot do by yourself. The people from whom you need help, stakeholders and SMEs, are busy people. You need to make efficient use of their time. Going in cold is not a good approach. In fact, they may find it frustrating because it feels like they’re teaching you the business. The good thing is, even if this is greenfield development, there is likely existing documentation that describes the business, its operating environment, and desired goals. After you’ve surveyed the existing artifacts, take these steps:

  1. Collect and organize them in a central repository. You will want to be able to get to them quickly when needed during interviews.
  2. Note who the authors are. They will be likely candidates for interviews.
  3. Create a short description of each document. You do not yet need to read in-depth. There will likely be too many documents for you to consume in the time available.

Now you can deep dive just on those documents that seem to you to be important. From this reading, put together a working domain model. This doesn’t have to be all-encompassing or highly detailed. At this point, you want an artifact that demonstrates your current understanding and primes the pump for the conversations you’ll have during the interviews.

The Context of Milk
A working domain model for the design of a milk jug

Interview Stakeholders and SMEs

Now that you have a basic understanding of the domain, it’s time to vet, correct, and expand it. The interview is your vehicle for accomplishing this. Ideally, these will be one-on-one sessions because you want people to talk freely, letting you know their insights and points of pain. You may get pushback, trying to get you to schedule sessions with multiple people. If this cannot be avoided, keep it small and stress-free. No more than 2-3 people or some will not have the opportunity to speak. Ensure that none are in a power position over any of the others. They will likely clam up in the presence of their bosses. Start with the primary stakeholder. They need to be kept happy and they will certainly know who else you should interview.

Before you schedule an interview, reach out to the potential interviewee to let them know your objectives (vetting, correcting, and expanding). This will give the person a chance to tell you that they are not the right one for this task, but here are some documents to read and other people you may wish to talk with. This is actually a really good outcome. It enhances the quality of your document base and interview schedule. It also frees up your time.

two women meeting using a pen and paper and laptop

I have found that the following agenda for each interview to be helpful:

  • Present your working domain model. Given the artifacts you’ve read and the people you’ve already interviewed, this is your understanding of the domain.
  • Does the model match the interviewees understanding? It’s rare, but not unheard of, to be way out of sync. It could be that the documentation you relied on is out of date or the people you’ve previously interviewed are coming at things from a different angle. It is your job to reconcile these differences. The most likely outcome is that the interviewee will provide you great detail that gets into the nuance of the domain. Finally, beware if they believe it’s a perfect match, especially early in this process. Ask them for additional details on an aspect of the model that they seem to be experts in.
  • Who else can you talk to? When wrapping up the session, ask them who else might have useful information to impart or if there are any documents you should read. Fold these back into your interview schedule and document base.

After each session, or, at most a day’s worth of sessions, incorporate what you’ve learned into your working domain model.


The domain model is a living document that describes your organization’s objects, actors, and interactions. As those change, so should your domain model. This artifact serves as an input to the problem statement and the framework you’ll build to judge possible solutions. It is important to keep in mind that at some point the model should graduate from a working one to a published version. Where that point is is something only you and your team can determine. There are no hard and fast rules except that it remains a living document. It’s never done until the product you’re working on has sunsetted.

As you iterate, keep the following in mind:

  • Make sure the domain model is up to date. Waiting too long could lead to difficulties in bringing the model into sync with your current understanding. Also, after you’ve published it and members of the team are using it, you’ll want to make sure they have the latest information.
  • Make sure your document base is up to date. This includes adding new documents as they become known, but also updating your short descriptions of the documents. The goal is to shorten the ramp-up time for anyone new coming into the project. They should start reading the most important documents.
  • Re-interview people when new information comes to light. At the very least, you’ll want to regularly meet with the primary stakeholder, if only to keep them up to date. But you will also want to talk again with people when information changes or there are conflicts in understanding. This might be a good time to bring the two parties into a room to hash those conflicts out.
  • Evangelize the domain model. Every time you publish a new version, let everyone know. In the pre-COVID world, I would print a large format of the model and tack it to the wall where we worked. I found that conversations tended to move to the model so that the developers could point to the various actors and objects as they discussed an issue. This is a great way to avoid confusion.

Let me repeat: Your objective is an artifact that will help you define scope, prioritize your efforts, and provide a common vocabulary that allows for efficient communication.

Additional Reading

  • Definition of Domain Model: As noted on Wikipedia, the definition of a domain model varies by where it’s used and by whom. Ten Mile Square takes an expanded view of the software development definition to include actors and stakeholders as well as objects, even those not directly used in any system we may be developing. The important thing is to have an expansive understanding of the universe in which you are operating.
  • How to Collaborate with Stakeholders in UX Research by Susan Farrell from the Nielsen Norman Group: While this specifically addresses UX research, the approach Susan describes applies equally to domain modeling.
  • UI, Usability and UX: The Square Milk Jug Edition: This is a domain modeling exercise I wrote up
Scroll to Top