I have collected the book “Patterns, Principles and Practices of Domain Driven Design" written by Scott Millett. Now I would like to complete this book end to end as well deepening my knowledge of Domain Driven Design, CQRS, Event Sourcing. Should I read the entire book and attempt all the exercises? What else can I do?

Hi,

I would highly recommend reading the book start to finish. At-least part 1 first to properly understand the philosophy of Domain-Driven Design.

Once you finish the book start focusing on language, and forget about code for now. Learn the language of the business. Understand where specific terminology applies (your bounded contexts). Start to then visual the system creating diagrams, using domain terminology (like names of bounded contexts). Create diagrams of key business rules, but do it with domain experts. Create a ubiquitous language (but call it a "business glossary") and get domain experts and stakeholders to work through it with you.

That's the collaborative aspect of DDD, and a bit strategic. Then move down to the strategic level creating more diagrams http://blog.ntcoding.com/2015/08/dom...-diagrams.html and validating them with domain experts. Try and do it collaboratively with your team to build a strong shared vision.

When working collaboratively and strategically, try and find out which are the core domains - what does this business to that distinguishes it from others. You may want to use a tool like the Business Model Canvas http://blog.ntcoding.com/2015/03/emp...nt-guided.html.

Once you've found the core domains, start modelling them in code. Try different models. Again, try this collaboratively with your colleagues, and try to talk domain experts through your model.

If you follow this advice you'll have a good practical knowledge of DDD - the collaborative, strategic and the tactical. Then keep practising iteratively, and try new exploratory techniques like event storming, impact mapping, and tactical patterns like CQRS and Event Sourcing.

Remember - focus on consistent language that is used to create a shared model in conversations, diagrams and code.

If you don't have a real problem domain to practice in, you can create a workshop. Create a fictitious scenario with functional and non-functional requirements. Ask some people to play domain experts, and the others have to work in teams and design a system. The output of the workshop could be some diagrams http://blog.ntcoding.com/2015/08/dom...-diagrams.html and a business glossary (ubiquitious language). Each team presents what they have learned about the domain and how their system will solve the business problem. Extra points for any team who focuses on the core domains and creates other visualisations like a business model canvas.

To make the workshop even more realistic your teams can be composed of a variety of skills: developers, QAs, product owners etc. If you do want to do a workshop but need some inspiration or example scenarios just give me a shout. I've run the workshop quite a few times and have some interesting scenarios that people really enjoy.

Enjoy