There is a lot of things to learn in here. Probably I should read it again. ( )

See elsewhere for my more detailed summary.

The short summary is that Domain-Driven Design is a great book for any programmer or software designer who wants to deepen their ability to model application domains. Evans describes why domain modelling is important and sets out a number of patterns for achieving better models. He has a good grasp of real world complexities and, because of that, insists that a model must be implementable if it is to be successful. Any overlap between the model and the implementation should be identical or the model will become obsolete.

Evans provides a number of patterns to help determine the best domain model for an application. These patterns range from the abstract to the concrete, from the brilliant to the pedantic. Overall, I highly enjoyed the book although, at just over 500 pages, I am glad that I had a reading group to work through it with.
( )

For some reason this book is greatly beloved in programming circles. I can't tell if that's because the people doing the beloving are die-hard Java Enterprise programmers, or if I'm just missing something here. But I think it's the former.

Domain-Driven Design is an excessively dry, boring book whose main thesis seems to be "make sure everybody agrees on what terminology is being used." What could have been this one sentence is instead 650 pages, chocked full of UML diagrams and insipid discussions about shipping containers. And that's saying something, coming from a guy who reads excessively dry boring math and engineering books on the regular.

If I had to be charitable, I would say that this book is independently groping towards functional programming without knowing it, and trying to shoehorn the ideas into an OOP-mindset. There is a lot of potential here for things to like, but it ultimately falls short. If you've only ever coded in Java, or frequently sketch UML diagrams, this might be the book for you. And if so, may god have mercy on your soul. ( )

This work was published in 2004 – a lifetime ago for the field of software design. It tackles issues relevant in 2004 but are standard practice today. Its basic message – learn not just the software but also the domain – is an important one, but most of the insights has been absorbed into computer-programming praxis over the last fifteen years.

Its strength is in delineating how the programmer is to relate to the domain experts who teach the programmer about the application area. He defines the term “ubiquitous language” to describe the language and concepts the two must share. I like this concept, but I think that the chosen wording should be “common language” instead of referring to the concept of ubiquity (whose meaning is closer to everywhere than shared or common).

This book had its time and place. However, for the $50 price current on the market, I suggest that its time and place has passed. It has contributed to history, and one should appreciate those effects. Nonetheless, contemporary design concepts – like Agile development or the DevOps movement – certainly deserve more attention from the reader.

( )

This is a great book for domain modeling. It should be required reading for programmers. Little things like using consistent language does make a big difference. ( )

On a topic which most authors would probably tend to evangelize, Eric Evans is conversational. His viewpoint is straightforward: these are the principles he feels he's extracted from putting in many, many hours on many, many projects. But he sort of slip-slides around the principles, approaching them from the back with lots of digressions on things his teams have tried; sometimes they work and sometimes they don't work, and maybe this general principle is sort of, kind of, why the ones that worked, did. Which is a bit of a breather if you're used to the typical snake-oil agile style where JOE USED ALL THE AGILE PRINCIPLES AND BROUGHT IN HIS PROJECT 30% UNDER BUDGET!

But Domain-Driven Design is tricky, much more so than the simple agile recipes like test-driven development and pair programming. DDD is much more about finding common ground with the people who use your software, or at least the people who represent those people, and so it's almost more a book on communication than it is on coding. But it isn't. Evans sticks strictly to the coder side of it, and focuses on how one extracts business logic and rules from business people, even when those people aren't completely clear on the rules themselves, which is most of the time.

So if you're the type of developer who just wants a spec to work from, and to be able to tell the boss, "can't change that - it's just like the spec says", feel free to skip this book. If you think domain levels are a waste of time, and you're happy with a UI layer that talks directly to the database layer, go ahead and skip this book.

But if you think that communicating with the people that actually use your software is important, or if you see software as a way to model business functionality, it's a must read. Because without some inkling of these principles, no piece of complicated, useful software could ever come into being. ( )

Following on from the original Design Patterns book by the Gang of Four this is a must read for anyone serious about taking the development to the next level. ( )

Clever and clear, even if somewhat slow-moving. Eric Evans knows where to lead the reader, and the book is full with plenty of useful insights. ( )

a