Well-Defined Domain Model is the Key to Success

One of the challenges in agile style of development is to delay making decisions that are crucial for the whole system. The key tool to achieve this, are iterations that allow us, based on the continuous communication, to collect feedback and to provide options as a reaction to the change. But there are some high-level decisions that you have to make at the beginning of the development. "High-level" means in this context, those decisions that would cause a very high cost if they would have to be changed.

One of the tools I'm using to amplify feedback from the customer is the domain driven design (DDD). It allows us to model the domain of the customer using a domain specific language and that makes the customer happy. We are using the language of the customer, thus he can understand us clearly, our questions and concerns and provide appropriate and detailed feedback. It works perfectly.

The problem that we have is to provide a well-defined Domain Model at a very early stage of development. Without clearly defined domain objects and their relations you are not able to define actions on them. You will get very quickly stuck. The second problem that can occur, are mistakes in your model. I have faced that in my current project. Our Domain Model has defined one domain object that was too generic, thus actually it didn't directly exist in our domain. It's like defining a domain object animal in case of the horse racing domain. The domain specific language of the customer doesn't contain the word animal, it uses the word horse instead and all actions of the domain are defined relating to domain objects like schedule horse race (and not schedule animal race). As a result of that mistake, a lot of business logic has hiked to the application/service layer, causing violation of separation of concerns principle.

The key concept to provide a well-defined domain model is to understand as much as possible from the domain. Invest as much time as you can to learn the domain using all possible instruments (interviews, brainstorming etc.). You can try to delay the decision regarding to your domain model, providing options, which means creating more than one domain model. But at the end you have to make the decision (if you don't do this, the decision will be made for you, which is the worst case). And please do not forget that it is very difficult to change or refactor the model later. It is also very difficult to build the flexibility into it. Especially try to avoid generalizing your domain objects to achieve that. They have to stay specific for the domain, otherwise you will lose the domain model purpose: to model the real domain.

The domain model is like a skeleton of your system. The whole body of the system "hangs" on it. And it is very painful if you have to break it. A well-defined domain model is the key to success.

---