Domain Model #

According to Larman¹, the domain model is a centerpiece of object-oriented analysis. It is primarily a communication tool, not an intermediate design step before programming. Larman¹ also refers to it as a visual dictionary.

It is not to be thus a 1:1 representation from the code, but the developers support, so that they understand the domain better and thus errors find missing contents in a specification.

Since the Domain Model describes the static side, often also a representation form for the dynamics of the system is often needed. For this purpose among other things the Use Cases or sequence diagrams offer themselves.

Advantages and disadvantages of Domain Models:

• In a domain model, the technical terms can already be clarified and defined with the business department. This means that a common terminology can be developed.
• The model can be created well from the customer’s point of view. Have we understood the customer?
• It is obvious what exactly is stored and then must be accessible.
• The dynamic aspects are not apparent.
• No change comparison of a diagram can be made. So only one person can single person can edit the diagram.
• Duplicated information can be easily found in the code. In a diagram it is not so simple.
• The diagram must have a standardized meaning, so that there are no misunderstandings.
• It should be created in a team effort, not just sent around by mail. There are valuable questions and answers when creating it.
• A Domain Model the size of an A3 sheet is easy to read on a beamer.

In the example above you can see that a customer can make several reservations. Each reservation has several article descriptions. For the reservation the exact product is not yet important but only the kind or in this example the article description.