On almost every family holiday I take a good book. Not being distracted by the continuous flow of the Internet and with enough time to let stuff sink in, holiday time makes a good time to see things in perspective again and come home with a fresh mind full off ideas. Last time this worked very well to give myself a real boost on building enterprise applications domain-driven style. Jimmy Nilsson's Applying Domain-Driven Design and Patterns was a quite pragmatic coding based approach which really accelerated my way of building applications. So this time I considered it time to finally do a thorough read of Eric Evans's bible of DDD

There are plenty of reviews on the web, on Amazon alone you will find loads and loads of information on it's content and value. Besides that it has a website. Fragments of it's content is found in so many posts on Codebetter that it almost seems implicit knowledge over here. But as I enjoyed it that much I would like to draw some more attention to this modern classic itself.

Inside you will not find a lot of code. Besides that all code is Java code; the .net platform is not even mentioned once. The book is about the essentials of code. All revolves around one central object oriented domain model. A model which serves the developer to write the implementation but it is also a model which speaks the language of the domain expert who understands the required functionality of the software. The model is described in an ubiquitous language whose meaning is understood in the same way by all team members and so serves good communication. By refactoring the developer as well as the domain expert work in cooperation on the same model. This may sound somewhat vague but chapter by chapter all aspects, from database persistence to a vision statement come by including very clear examples. Reading gave me many points of recognition as well as some aha-moments. A very pleasant moment was the conclusion of part 3, Crisis as an opportunity, where Eric mentions "punctuated equilibria", the (r)evolutionary model of a recent rant of mine. How a domain model can evolve over time also fits perfectly in that story.

At first I only felt sorry I had waited that long to start reading (or going on a holiday :)). The book is written very clear, does give a great overview of the subject and is very systematic in making its point. It is absolutely a classic that every developer, architect (is there a real difference ?) or anyone else who is involved in building software should read. Not everybody does agree on this, between all the five star reviews on Amazon you will find some less enthusiastic ones. So, on second thought, I would not always recommend this book as a starting point for DDD. In case you have troubles reading it start Jimmy Nilsson's Applying DDD and patterns and make sure you really start doing some hands-on DDD stuff yourself. And sooner or later you will really appreciate this book as it will structure all you've read and done back into one clear and flexible model. And that's what DDD is about.

And now you should start reading it yourself.