The Five Characteristics of a Good Domain Model

I was trying to figure out a good definition of a domain model for this blog entry. All of my efforts led in to a somewhat clumsy explanation. However, I was able to find a good definition of a domain model from Wikipedia:

A domain model in problem solving and software engineering can be thought of as a conceptual model of a domain of interest (often referred to as a problem domain) which describes the various entities, their attributes and relationships, plus the constraints that govern the integrity of the model elements comprising that problem domain.

Sounds important or what? In other words, a domain model is an essential part of every application and it is a representation of real world concepts. But how can you distinguish a good domain model from bad one? The answer to that question is not obvious because understanding the domain model requires that you also understand the problem domain. My goal is to make this task a little easier by describing you the five characteristics of a good domain model.

A domain model is likely to be a good one if it

Models the problem domain correctly. A good domain model is not necessarily an exact copy from the real world, but it must model the problem domain with the required accuracy. This means that it must contain only the information, which is relevant for solving the given problem. Unnecessary information must be excluded from the domain model even if it would exist in the real world. However, containing the right entities is not enough. The associations of those entities must be correct as well. The problem is that before you can judge a domain model by using this criteria, you should have some knowledge from the problem domain.

Speaks the right language. Because a domain model is a representation of a problem domain, it is essential that its elements have been named correctly. This ensures that both the client and the subcontractor are speaking the same language. Speaking the same language is important because it minimizes the possibility of misunderstandings, which reduce the quality delivered to the customer. Verifying if the analyzed domain model fulfills this requirement is quite simple. If the elements of the domain model have been named correctly, your customer should be able to understand it without problems.

Claims ownership of its information. A good domain model controls the changes made to its information. This means that it should provide methods for manipulating its contents and prohibit all other changes to the information under its control. Providing only a single access point to the information of a domain model has two major advantages: it reduces duplicate code and protects the integrity of the domain model. Thus, following this guideline will lead in to cleaner and less error prone code, which should be the goal of every software engineer.

Also, if you need information, which is based solely to the domain model and has not other dependencies, you should place the method providing this information to the domain model. This approach follows the separation of concerns principle and it will improve the quality of your code by clarifying the architecture of your software.

Following these guidelines will also help you to avoid an anti pattern called Anemic Domain Model.

Provides built-in support for logging. Because it is often useful to write the contents of an object to a log message, a domain model should provide a simple way to obtain the contents of an entity as a string. This ensures that you do not have to construct log messages manually. All you need to do is to append the object in question to a log message and you are good to go.

Is covered by unit tests. This characteristic of a good domain model is kind of obvious (at least for professionals), but I have learned that assumptions can be dangerous. That is the reason why I wanted to write down a few words about unit testing a domain model. Even though I know that precise guidelines can be dangerous, I think that in this case it is possible to present an exact guideline for unit testing any domain model. You must simply test every method, which is not a getter or setter method.

I have now described you the five characteristics of a good domain model. I hope that this blog entry will help you to differentiate a good domain model from a bad one, and maybe give you some tips how you can transform a bad domain model to a good one.

PS. If you have design a domain model from the scratch, you might find this presentation about domain modeling useful. Also, I can recommend a book called Domain-Driven Design by Eric Evans. It is full of useful information about domain modeling and in my opinion it is a must read for every software developer.

7 comments… add one
  • TAMIRU ABERA Nov 5, 2013 @ 15:51

    your way of explanation about "characteristics of a good domain model" is very interesting. Add more. Thank you!

    • Petri Nov 5, 2013 @ 20:10

      Thank you for your kind words. I really appreciate them. I am going to write more about this (domain driven design) in the future.

  • Theophilus Godswill Mar 13, 2018 @ 8:04

    Thanks man.....

    • Petri Mar 13, 2018 @ 10:05

      You are welcome.

  • Xiyuan May 10, 2019 @ 4:19

    why did u think " but I have learned that assumptions can be dangerous"?

    • Petri May 11, 2019 @ 20:05

      It just means that it's dangerous to assume that people will write unit tests for their domain model. Also, I wrote this blog post almost eight years ago, and to be honest, it feels "a bit" clumsy. In other words, I think that you shouldn't pay too much attention to the advice given on this blog post.

      • Xiyuan May 13, 2019 @ 14:32

        Thank u so much….

Leave a Reply