Designing domain models is probably the first thing that every software developer learns in school.

The concept for good domain model is quite simple: diagram representing the business objects (entities) in a system and the relations among them.

The purpose of the domain model is to create a common language, terminology and understanding for the system and the business around it.

Even though it might be a simple and well-known definition it somehow seems to be also quite tricky and hard to follow through.

Step 1: Identifying the right entities (business objects)

The easiest way to identify the entities in a domain model is to look through the case story and highlight all significant nouns in it.

Here is one example of a bad Dungeon game domain model (that is a real model that I recently received, the only alterations that I did is to remove the method definitions from the Game entity, because they weren’t the most disturbing part in it.)

Why this is a bad domain model?

1. It doesn’t give any idea for the system’s structure, doesn’t help for a better understanding of the system and creation of common language among developers and clients. This could be easily the domain representation of any game out there.
2. SavedGames: here is one disturbingly strange entity, which represents a rooms, items, players and etc. is a saved variant. But how can one possibly imagine how SavedGames look in a real world example. We could imagine it as a box where we put everything which is relevant to the game. But if we say that we have not saved game so far and the box is empty, do we really have a SavedGame object and who needs a empty shell of nothingness?

Here is how this Domain model was transformed to comply with the standards for a good domain model.

Why this domain model is better?

1. It gives an overview of all real objects that are involved with the game entity.

2. It gives a representation of the relations and the valid states of this relations (Player which has less or more than one current Room at the time is in invalid state; Player with exactly one current Room is in valid state)

3. It gives and idea what properties are needed for the entities.

4. It provides a base for common language and understanding between developers and clients.