Domain Driven Design, Software, Team

Software Development – Domain Drive Design

I bought a book about DDD (Domain Driven Design). It’s about this software development methodology. It seems pretty interesting. I’m still at the beginning what I have understood is that developers should work alongside domain experts. This allows developers to distil knowledge from domain information to build a model. This model will be used in software prototyping and/or implementation. This implementation lets refining the model through domain experts’ feedback. The refinement triggers software modification so we can iterate through this process. All the process allows improved models where terminology is always more defined between domain experts and developers that will be used for significant improvements.

Important elements of the process are continuous learning and prototyping/implementations. These allow developers by domain experts’ feedback to validate what they have learned about the domain. On another side they allow domain experts to learn about the rigorous world of software development.

A key principle of DDD is that developers must learn about the domain by working alongside the domain experts that learn about software modelization.

So, what I think, and this is my personal conclusion, is that developers should care about their products and stakeholders. They cannot think to do only technical knowledge acquisition, or get the knowledge of the domain only from the analysts. They cannot ignore the domain. They must have a knowledge of the model as clear as possible.

Standard