First, this is a good book. I'm new to the domain-driven space and formal OO design so this way a big bite for me. But I know this is a seminal text so I decided to give it a try. The reason I said this is a soil-breaking book is because it really digs around in the ground for a person who has never been taught these concepts before.

If you're also new to DDD, you WILL learn from this book, but you will NOT be an expert at the end. In fact, the concepts presented in this book have confused me even more. This is not a knock on Evans, but a commentary on how unfamiliar some of these ideas are to me.

With that said, Evans has given me a whole new set of categories and vocabulary into which I can begin to fill in the missing pieces. This is the process of learning!

His examples in the book are from real life but the domain knowledge (e.g. shipping industry, circuit board printing, etc) necessary to understand them is sometimes substantial. This makes understanding his main point tough because you can't see how it actually works out in real life (since you can't understand the example), so his point remains an abstraction you also can't understand. But I don't blame him for this. We developers will either complain that an example is too arbitrary (animals/cats/dogs when discussing polymorphism) or too specific (as is the case in many of his examples). Only ~30% of his examples fall into this category.

One thing I would strongly recommend before reading this book is to have read a book on patterns and understand what they are, why they're used, and even some specific examples of patterns, namely, the repository, strategy/policy, and specification patterns. It will help you to understand extended sections of the book with more clarity.

In all, I think this is a good book. Knowing what I know now, I would definitely read it again. When I gain more insights into DDD, I may come back and read it again.

This book has a lot of useful design principles, but they can be hard to garner and retain because the writing is very dry. I almost wish the suggestions were of lower quality, so that I would have had an excuse to stop reading the book. In the end, it took 2 renewals from my library to get through Domain Driven Design.

The other downside to the book is that it did not provide a clear path for me to incorporate many of the practices that it lays out. It seems like one would need an extremely high functioning and close knit team and organization to implement the suggestions in the book, and it's unclear to me how much one could do without such an ideal situation. While I can apply many of the specific design principles to my own tasks, I do not know how to leverage the larger practices of domain driven design in my organization.

This book radically changed the way I design software. Domain modeling gets to the heart of object-oriented programming. The book is a bit academic and long-winded, but very deep and complete.

This is an immediate classic and required reading for any serious engineer.

If your process for writing an application is to start with the database, or to start designing UI, you should read this book.

There is nothing new in this book -- but you really should read it.

This book details the way many architects and analysts have been creating their applications for years, and for good reason. They start by creating domain classes that help represent data in a way that is understandable to both developer and customer. Then building out the application from there.

Read this book.

This book is just amazing. In this design world, there is so much to look for, and this guy just brings it all into one book. He answers the questions you have been asking. He compiled a lot of knowledge people already had into a wonderful set of ideas. Get it.