Domain-Driven Design review

Domain-Driven Design, by Eric Evans, is the masterpiece of the DDD movement. It introduced to the world the harvested experience of Evans in working on model-driven development on a variegate group of object-oriented projects, presenting it as a series of patterns and meta-patterns (such as the Ubiquitous Language), and ranging from the design of a single class to a large map of different applications.

A brief summary
DDD is a very dense book, and it is logically divided in four parts:

• Putting the Domain Model to work, which covers the importance of the Ubiquitous Language and the centrality of the model of the application domain.
• The building blocks describes the patterns used at the finer level, such as Entity, Value Object, Aggregate, Service, Factory and Repository. 
• Refactoring towards deeper insight covers the continuos process of adapting the Domain Model to new insights and crunched knowledge, believing firmly that an hidden model exists and will be reached with a supple design. Modelling as described here is like applying an unification theory to software.
• Strategic design introduces the techniques for large scale structure and separation of contexts, such as the famous Anticorruption Layer (although it is not the only communication medium between different Domain Models.)

In my opinion the third and fourth parts are the most difficult to digest, due to their abstractness (not everyone of us has worked at that scaling level) and the perceived distance from working code. In fact, the first two parts are rich in code samples, which gradually vanishes towards the end of the book while the view on object-oriented applications is taken to an higher level. Diagrams, both based on Uml and not, are preferred throughout the last chapters.

How to read it
Many people start reading DDD full of confidence, scheduling five chapters a day, only to struggle very quickly, usually in the second part, and abandone it. Even in my recently completed reading from cover to cover, I waited some time before starting the third part.
This book is intended as a series of patterns - notice the capital letters used for most of the names - those names are specific terms with a precise meaning. In the case of the Gang of Four book on design patterns, this made it hard to read cover to cover because of the lack of a common thread between the chapters.
But in this book's case, the main theme is the model-driven design practice that evolves from the finest level - the class and its methods - to BoundedContexts and Responsibility Layers. That said, the information contained is very dense and I have never read more than 15-20 pages on a given day. I suggest you do to the same or you risk burning out before reaching half of the book. Also taking notes is a mean that forces high focus of the content and may help.

Other resources
There is a lighter book freely available - Domain-Driven Design quickly - which promises to explain you DDD in 100 pages. Don't read it: when I tried, I understood a concept only as long as I have already read it on the original DDD book, and never learn anything on the new material. The original is 400-page long, but it is already condensed as much as possible.
A book that expands on the code samples and the design process is Applying Domain-Driven Design and Patterns, which is a good read to combine with DDD (in fact, it is 600-page long.) You may refer to it when you want more practical examples of a pattern treated in the original book.

In sum, this book is often cited as the DDD book, and in the future it may be considered the bible of real object-oriented development. If you have it on your shelf, I suggest you to read as much as you can beginning from the start, skipping only the fourth part if you do not ordinarily deal with large-scale applications.