DDD.1 – Crunching knowledge

Developers and Domain Experts collaborate, discussing the Domain Experts knowledge, distilling it into all, and only, the knowledge relevant to the project.

The objective is to end up with a model of what the application should do, how it should do it, and what the technical implementation should be.

Knowledge crunching is not a one time activity, like in the waterfall methodology. Although it should indeed be more intensive in the beginning of a project, it must be a continuous and iterative process, where the model is built and improved as developers gain knowledge about the domain and the technical challenges of the project. The domain model grows side by site with the application itself.

Effective modelling is based on:

1. Binding model and implementation
   The implementation is strictly based on the model;
2. Cultivating a language based on the model
   The model contains terms which are the base of a language common to both Domain Exerts and Developers;
3. Developing a knowledge rich model
   The model must be more than a representation of data structures, it must contain all kinds of knowledge. It must contain ideas, data structures, objects, behaviours, enforced rules, etc.
4. Distilling the model
   A model must contain all, but also only, the relevant knowledge. This means that as we gain knowledge about the domain, we add the relevant knowledge to the model, but we can and must also remove, from the model, the domain knowledge that we end up figuring out that is not relevant after all.
5. Brainstorming and experimenting
   Brainstorming and experimentation meetings between domain experts and developers, where massive experimentation and discussion takes place, is what ends up providing a distilled and knowledge rich model.

The most productive teams are continuously learning about:

• Technical knowledge
• Domain modeling knowledge
• Knowledge specific to the domain of the project

The developers who, throughout time, become domain experts themselves are the most effective knowledge crunchers and, as such, the most efficient and perhaps important team members.

This post is part of a set of posts with my personal notes about all the chapters in the book “Domain Driven Design” by Eric Evans. I will do this as I read through the book, and take notes on the concepts I personally find more relevant.