Domain Driven Design by Eric Evans

What is Domain Driven Design?

The idea is to create a model of the domain. You do this by understanding, collecting and organizing the knowledge of the domain experts and putting it into the model. The domain is the area in which the software is supposed to solve problems. So in a banking application the domain model contains the knowledge of banking, in a application of insurance company the domain contains the knowledge of insurance. The domain model should contain the concepts used by the domain experts. The implementation of the domain model should also show these concepts.

When starting to work in an new area software developers do not have a deep understanding of the domain. So when a software project is started the team does not understand completely what the software is all about. It is critically important that they invest in learning about the domain. This learning keeps going as long as the project is going on. More and more insights come up and should be added to the model. If the old model does not fit to the new insights anymore then refactoring can be used to keep the model and its implementation up to date.

The goal is to have a domain model that allows new customer requirements to be naturally solved within the model.

How do you notice your model is not so good yet?

  • When there are many complicated “manager” and “calculator” objects. There is a good possibility that there is a concept missing in the model. A missing concept in your understanding of the domain.
  • When new requirements come up that do not fit into your current model.

How can you find out what could be missing?

One way is to talk to the domain experts. Look for words in their language. Words you don’t quite understand. This can be quite difficult. To the domain expert that concept is obvious and they most likely did not notice, that you are missing that concept. If you find the missing concept and tell the domain expert about it he will likely say: “Yes sure why did you not do it that way from the beginning?” He probably thought you couldn’t do it his way because of a technical software reason. Another hint that probably your design is missing a concept is when the domain expert says that he does not understand your model because it is too technical.

Ubiquitous Language

An important expression in domain driven design is the Ubiquitous language. This is the language used by the domain experts and the software team to talk about the domain and the domain problems. Concepts in the ubiquitous language will be found in the domain model and the implementation of the model.

Interview with Jimmy Nillsson

Here’s a short interview with Jimmy Nillsson an expert in domain driven design:

Leave a Reply

Your email address will not be published. Required fields are marked *