Domain modeling is the most important part of software design. Having a good model allows developers and business to have a common language, which in turn, makes much simpler the communication of requirements and the maintenance of the application.
Having a good model is synonym of having a low representational gap. Having a low representational gap means that the main concepts and their relationships from the real business model are represented almost identically in the software domain model.
Creating a good domain model is one of the most difficult challenges developers have to face. What follows are some advices to create a good domain model
1.- Understand the business model completely.
In order to create a good domain model, developers need to look into the detail of the the business model, not only in the surface. It requires to understand and distill the main entities and then find their closest equivalent software abstractions.
2.- Use good names for all your domain model classes.
Naming is critical in software domain modeling. There are two qualities that you should be looking for in a good name for an entity in your model:
- Consistent. Business and developers should always use the same term to define a single concept.
- Exact. A name should exactly define the responsibilities of an entity in the domain model.
3.- Use metaphors.
Many times is necessary to model abstract operations/entities in software development, (processing orders, simulations…), for these cases, metaphors will help you to simplify the design of the domain model.
4.- Make the domain model self-contained.
The domain model should contain the raw logic of the application. Any additional logic should be contained in some other layers, as for instance the work-flow, dependency injection, persistence…
5.- Make the domain model independent.
The domain model shouldn’t change because the underlying persistence implementation or the UI or any other layer changes.
It should only contain POJOs. The responsibilities assigned to an entity in the domain model should be limited to only those necessary for the software domain
7.- Keep the domain model updated.
Synchronize it always with the business domain model, having two unsynchronized models is one of the biggest sources of productivity killers. Synchronization requires refactoring and enough test coverage to make sure that things don’t break as they are refactored.
8.- Make the software domain model match the business domain model.
A software domain model should be easy to understand for a business domain model expert and it shouldn’t have any discrepancy.
There are two reasons why you want to make sure that the code quality of the domain model is top-notch.
- The domain model is the foundation of your application, if it is bad, the whole thing can fall apart
- It changes a lot. There are very few areas in your code that are going to change so many times as the domain model
10.- Test the domain model independently, and involve the customer in the test.
As already mentioned, the domain model is an independent and very important part of the architecture of the application. That’s why is so important to pay attention to test it in isolation. Involving the customers in this test phase can be very productive as they can identify test cases that are likely in production and which probably are the most interesting ones to test.