Domain Model Diagrams Using Class Diagrams

Domain modelling is the primary way of determining the important aspects of a business. It is usually created collaboratively by engineering, product, and business stakeholders to ensure all major parts of the business are aligned on what the domain model looks like.

That makes it a good candidate for diagramming. By documenting your domain models with a diagram, that domain model is really going to come to life, and is more likely to be practised. Furthermore, due to the ease of a tool such as MermaidJS, it's possible to create a draft of the domain model in real time when discussing with colleagues in a meeting.

I'd really recommend reading Domain-Driven Design: Tackling Complexity in the Heart of Software if you're keen to learn more about DDD.

Once you've got to grips with domain modelling, it's going to make your life so much easier. There will be moments during domain modelling where suddenly it all comes together, everyone is on the same page in terms of their understanding of the landscape, and everyone is speaking the same language.

The most powerful use of DDD I've experienced was working for an insurance company. The team I was working in had been tasked with creating a way to determine how exactly our products were sold, and to whom - sounds pretty easy, right? Unfortunately, the data was all over the place, and there were many avenues customers could use to make a purchase with varying data available in each avenue. None of us had any idea how to represent these conceptions in our code, so we spent several days domain modelling. We tried out different ideas and approaches, and in the end we landed on culmination of a few different ideas, and were easily able to translate the domain model into code.

I find the biggest power that comes from domain modelling is the collaboration, how it brings everyone on the journey, and ultimately to the same destination. It comes easy to talk about what we are working on, as we're all speaking the same language, and the code flows easily because we have a clear idea of how we should represent theses business requirements using our domain model. By the end of the project, even non-technical stakeholders were using the same terminology that we had come up with while domain modelling.

The final selling point I'll make for DDD is its ability to allow your domain and code to evolve over time. Because we're documenting our domain model diagram, we can reference it at any point. It's very common for new requirements to come along later, at which point we can refer back to the domain model, see if it fits the new requirements, and if not, it can evolve and adjust as necessary. The core of the domain we modelled at the insurance company is still intact today, but has since evolved to add new entities and use cases.

One type of diagram available to us is called a Class diagram. This originates from Unified Modelling Language (UML). A class diagram can be used to model classes, but it can also be used to model domains, which makes a lot of sense when you consider your domain model is implemented in your codebase with classes. The real power of the diagram is realised when we start to model relationships between entities, which we can easily do with a UML class diagram.

What Does A Domain Model Diagram Look Like?

Now that we understand what a domain model is, and what its purpose is, let's look at an example of a domain model diagram. This is a domain model diagram for a fictional streaming company.

          classDiagram
            direction LR
            Title "1..*" -- "1..*" Genre: is associated with
            
            Title "1" *-- "0..*" Season: has
            Title "1" *-- "0..*" Review: has
            Title "0..*" o--  "1..*" Actor: has
            
            TV Show --|> Title: implements
            Short --|> Title: implements
            Film --|> Title: implements

            Viewer "0..*" --> "0..*" Title: watches

            Season "1" *-- "0..*" Review: has
            Season "1" *-- "1..*" Episode: has

            Episode "1" *-- "0..*" Review: has
        

This diagram was created using diagrams as code.

This is just a subset of the entities a streaming company might need. In Domain-Driven Design, this would be called a bounded context. Within a given company, there is the entire problem space it works in. However, within that problem space, are lots of smaller spaces, which we call bounded contexts. There's no "right" number of bounded contexts to have per company. As an example, the diagram above might depict the "content" bounded context and its associated domain model. There might be others such as customer, or payment.

Creating a domain model correctly can be tricky. There's a lot of detail in the diagram above. In short, it shows all of the important concepts within the domain model, and how they are related to one another.

If you enjoyed this domain model, you might want to look at another domain model example, covering an entirely different domain.

Learn To Create Domain Model Diagrams

This was an overview of what a domain model is, and what a domain model diagram looks like.

The diagram above was created using a tool called MermaidJS. It allows you to easily create a variety of diagrams in Markdown-like markup, and quickly convert into a rendered diagram wherever you need it.

Want to learn more? I cover how to create domain model diagrams, along with a number of other use cases and diagrams, in my book: Creating Software Using Modern Diagramming Techniques, published via The Pragmatic Programmers.