Domain Driven Development with Agile

Recently I have been involved in a project that introduced domain driven design or DDD. An important aspect of DDD is the concept of the domain model. The domain model are a set of objects that correspond to your business domain, and as such, need to have as little technology and infrastructure related concerns as possible. As a general rule, as much business logic should be contained in the domain model so as to ensure they are not “anemic”, or devoid of logic and having simple data structures with no logic or validation assigned to them.

However, it takes work to construct a rich, robust domain model, and the construction of such a model should not interfere with the iterative approach with designing a system that satisfies stakeholders needs. If you are pushing logic into the domain model and you are not 100% sure that that logic is correct, you are in for a waste of time and resources. Therefore it is advantageous to have many working sessions, along with mock ups and prototypes, that delve into the logic that is needed within the domain model before enriching it. I think this is a very important graph to display:

Figure 1: Anemic vs. Rich domain model

It is important to note that proper DDD takes time, and in an ideal world you would like to deliver working software increments in stages such as every two to three weeks, this has to be factored into an organizations approach to DDD with enriched domain models.