3 of 3 people found the following review helpful
5.0 out of 5 stars Read this book to graduate from programmer to designer
I think that this book along with Robert Martin's "Agile Software Development, Principles, Patterns, and Practices" and Martin Fowler's "Refactoring" are perhaps the three most fundamental prerequisites for making the leap in knowledge and maturity from object-oriented programming to true proficiency in object-oriented design. The books from Martin and Fowler cover the...
Published on Sep 24 2003 by Brad Appleton
4 of 4 people found the following review helpful
3.0 out of 5 stars Reality Check - Yet Another Patterns Book
I bought this book due in part to the glowing reviews here on Amazon so I feel a duty to inject a bit of skepticism, now that I've read it.
5 stars for a technical book indicates to me a book of profound quality that really breaks through with penetrating insights -- The kind of book that makes me think, "Wow, this book has really brought my development practice...
Published on Jun 24 2004 by Vladimir Levin
Most Helpful First | Newest First
4 of 4 people found the following review helpful
3.0 out of 5 stars Reality Check - Yet Another Patterns Book,
This review is from: Domain-Driven Design: Tackling Complexity in the Heart of Software (Hardcover)I bought this book due in part to the glowing reviews here on Amazon so I feel a duty to inject a bit of skepticism, now that I've read it.
5 stars for a technical book indicates to me a book of profound quality that really breaks through with penetrating insights -- The kind of book that makes me think, "Wow, this book has really brought my development practice into a renewed, sharper focus." It doesn't necessarily have to provide radically new material, but it does have to package whatever material it contains in a way that causes the gears in my head to shift around and reorganize themselves. Design Patterns is such a book. XP Explained is such a book. I don't think this one qualifies.
Some good points: The author makes a good case for agile development/extreme programming (close relationship with the customer, unit tests, refactoring...). He seems to believe there may be a tendency to over-emphasize the importance of code and to neglect design in such practices, which may or may not be true in industry at large. But in any case, his major thesis is that it is also important to consider the overall domain model and how well-aligned it is to the goals of the business. He proposes developing a common ("ubiqitous") language between developers and business users, and to unify the various traditional views of a software system (requirements, analysis model, design model, etc..) into one. The advice is quite wholesome and will hopefully promote bringing some harmony between the agile camp and the adherents of high-ceremony approaches such as RUP and CMM.
Some bad points: The book is rather wordy, and a lot of common-sense ideas are repeated at length. I don't feel that the patterns in the book are much more than re-statements of basic principles of OO design. I am not convinced that giving every possible variation on OO programming a fancy name is particularly helpful. Most of the patterns in this book come down to "produce a clean design that removes duplication and attempts to match the business domain." If you're new to OO, I suggest you'd be much better off reading some other books, such as GoF's Design Patterns, Fowler's Refactoring, Page-Jones' Object-Oriented Design in UML, and Kent Beck's XP Explained.
I give this book 3 stars because it's not a bad thing to read a book that makes you think about the importance of the business domain when programming. It's true that this emphasis, while fairly basic, does get lost in a world where specific technologies dominate good design and common sense. I don't think this book can really hurt -- although I have found the "declarative" approach it mentions can be very dangerous in inexperienced hands and can produce utterly unmaintainable code. It's not a bad effort, but it's not an earth shattering revelation either.
3 of 3 people found the following review helpful
5.0 out of 5 stars Read this book to graduate from programmer to designer,
This review is from: Domain-Driven Design: Tackling Complexity in the Heart of Software (Hardcover)I think that this book along with Robert Martin's "Agile Software Development, Principles, Patterns, and Practices" and Martin Fowler's "Refactoring" are perhaps the three most fundamental prerequisites for making the leap in knowledge and maturity from object-oriented programming to true proficiency in object-oriented design. The books from Martin and Fowler cover the software solution design space and the core principles and patterns for making code that is resilient to change and easy to maintain. Eric Evans book covers the problem domain space and the abstraction skills that free programmers to "break out of the box" of the implementation domain and solution objects into the critical area the business domain and corresponding domain objects.
I once led a young software team and tried to convey the need for and essence of these skills to them, but I didnt have the right words and terms to do it for their level of experience. I wish this book had been available to me then because I think it would have made a real difference for that team.
1 of 2 people found the following review helpful
1.0 out of 5 stars A real disappointment,
This review is from: Domain-Driven Design: Tackling Complexity in the Heart of Software (Hardcover)This book sets the expectations for grandiose and profound insights on software engineering, but it really failed to deliver.
To be fair, there are some good insights, but they are buried in lots of 'water' and structure less presentation. The points that author wants to emphasize appear in bold. Instead of bolding important things out, how about refactoring this book from 500+ pages to 200?
But the amount of 'water' is by far not the only problem with the book. For example, the author has made a point to use lots of practical modeling examples in the book. However, these examples lack continuity, as he they try cover too much. It would be better to develop 1 example through entire book.
I thought I knew what Domain Driven design was before I read this book. I think that people, who did not, would not get clear idea of what it is. A simple, single message that software needs to capture the underlying phenomenon being modeled is not really coming through.
The first few chapters focus on explaining what the Domain Driven Design is. Lots of emphasis is put on discussing the model with the customer in order to extract the essential concepts from the problem domain. While this idea is great, the suggestions that customers and engineers will speak the same language, where things are described like this: 'Car maintains collection of wheels', is rather strange. I do not believe that customers need to know that Car class actually stores wheels.
The following chapters proudly introduce Entities, Value Objects, Services and Modules - the core of Domain Driven Design. I found these ideas trivial. What is new in anything that's been presented? Also, author raises a lot of complex questions such as identity management and shared access, but does not really answer them.
The rest of book I can't really describe because things are just out of order. Not only I find no connection between chapters, the pages inside the chapter do not follow one another.
To sum up, I regret that I spent my money on this book.
5.0 out of 5 stars A must read for any business developper,
This review is from: Domain-Driven Design: Tackling Complexity in the Heart of Software (Hardcover)If you are the kind of developper who not only want to do stuff, but do them right, then this is the book for you. Erics Evan explain a lot of useful pattern to solve commonly encountered problem in the business software world. Reading this book really helped me improve the quality of my code. A really good point of the book is that it describe real world problems for which no perfect solution exist, and goes along to explain various solution and weight the pro and con of each.
The book require you to have some experience in the developpement world and reading Design Patterns: Elements of Reusable Object-Oriented Software and/or Patterns of Enterprise Application Architecture beforehand is recommended. However even a moderatly novice developper can benefit from this book if she is ready to document herself when an unknown elemen is introduced
4.0 out of 5 stars Worth a look,
This review is from: Domain-Driven Design: Tackling Complexity in the Heart of Software (Hardcover)I bought this book after seeing Eric speak at XPAU in Calgary (2004). He gave an interesting talk and so I took a flyer on his book. It's a big, heavy book (I ride my bike to work).
His suggestions around removing disjointed language when describing the domain, while nothing new, were a great reminder. It's one of those books I like having on my shelf, pulling down and leafing through from time to time.
A great collection of thoughts Eric, well done.
5.0 out of 5 stars One of the best software books I've read,
This review is from: Domain-Driven Design: Tackling Complexity in the Heart of Software (Hardcover)I read this book in its draft form on a cross-country flight and was just blown away by it, enough so that I bought a bound version to make it easier to carry around and reread.
I suppose what blew me away was that Evans crystallized and laid out quite clearly about a dozen ideas which were existing at the edge of my consciousness, but which I could not clearly verbalize.
It fits quite nicely between the patterns books and the process books, but it's not a cookbook and it's not strictly a method. It's a must read for the multitude of Java/C#/C++ developers who continue to write procedural code while claiming they're OO developers because they're using an OO language and they've read Design Patterns.
4.0 out of 5 stars Essential Knowledge for Designers of Non-trivial Systems,
This review is from: Domain-Driven Design: Tackling Complexity in the Heart of Software (Hardcover)Even if we're geeks from birth, and grow up playing with tinker toys or legos and graduate to software or electronics and then make it through engineering or software school with high marks, most of us never really encounter extremely complex problems until we are employed in industry. The result is that we are pushing thirty before we encounter problems that we can't simply jump into and starting building the solution for. We end up approaching every problem with tools and materials in hand, neglecting the important problem space analysis that must come first. Evans does a superb job of explaining how OO analysis of the problem domain leads to natural, sensible reflections in the solution space. It may be that there are too many words in this book, and it may be that the ordering is a little off, but the message is dead on, and shouldn't be ignored by anybody who's serious about solving very complex problems with software. If software is part art and part science, this book describes the art very well.
5.0 out of 5 stars Remarkable advice & approach,
This review is from: Domain-Driven Design: Tackling Complexity in the Heart of Software (Hardcover)If the advice and the underlying processes and procedures outlined in this book are followed any software engineering process or lifecycle approach will be dramatically improved. Note that the material in this book is as applicable to agile methods as they are to heavy approaches, including the still used waterfall SDLC.
Why five stars? Because this book peels off the layers of what is wrong with development, discarding them and replacing them with alternatives that promote communications among all stakeholders, placing design into its proper context, and provides the glue that binds subject matter experts from business and technology domains into a cohesive team using the same language and pursuing the same goals. On the surface this seems like common sense, but in practice, it is rarely done. Indeed, the lack of the ingredients given in this book on most projects is the reason why so many projects fail or are cancelled, and why there exists today a real disconnect between IT and the business. Following this book, implementing the practices, and managing to them will make a world of difference in the success rate of any organization, large or small.
I like the copious examples to illustrate the technical concepts, and especially chapters 9 (Making Implicit Concepts Explicit) and 14 (Maintaining Model Integrity) because these are two areas in design that I've observed to be potential failure points - the first because too often wrong assumptions are made and locked in, and the second because models sometimes take on a life of their own and morph into unintended things.
This book emphasizes a number of critical success factors, including knowledge, communication, control and vision. If the material is approached as merely an intellectual exercise then you'll probably be dissatisfied with the book. If, on the other hand, you are genuinely seeking a solution to a high project failure rate or disconnect among stakeholders, and are willing to do what it takes this book will provide a blueprint for success.
5.0 out of 5 stars Concretes the abstract worlds of patterns and principles,
This review is from: Domain-Driven Design: Tackling Complexity in the Heart of Software (Hardcover)This book answers the question of how you tie in cookbooks like the GoF book or Fowler's Enterprise Patterns book with the Wirfs-Brock book on designing systems. Reading this will help you to understand how to identify and apply great patterns in your design, where and when those patterns are important, and how many resources it's worth investing on rolling them out. More importantly, it helps you to understand and convey to others the importance of a clean design model.
I also really enjoyed his notes on large refactorings (yes, in practice, sometimes you *do* encounter the need for large changes!) and the author's pragmatism around having to make decisions about where you invest heavily and where you don't. His points around large project constraints and how it becomes non-linearly expensive to maintain continuous integration and design consistency to the finest detail also hit home -- I've seen more than one group try to do that, fail, and give up entirely. A bit of balance, as he advocates in the book, would have really helped maintain some consistency and a solid core without requiring moving heaven and earth to get every interface looking Architect Approved (tm).
The only place the book was lacking was in how you tie together and manage quite a bit larger projects. For instance, near the end he says, "No project will ever employ every technique in this book"; however, I've been on one that used everything he mentioned in this book in one place or another -- of course, it's tens of millions of lines of code :-)
5.0 out of 5 stars Superb and original,
By A Customer
This review is from: Domain-Driven Design: Tackling Complexity in the Heart of Software (Hardcover)This book is truly an original work. It shows that the author took his time in writing and editing this book - it is not slapped together like so many technical books these days. The layout is very professional; nice lack of gimmicky icons. My only complaint is that the language and examples can be almost too intellectual at times and take a long time to work through. But it is worth it!
Most Helpful First | Newest First
Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans (Hardcover - Aug 20 2003)
CDN$ 72.99 CDN$ 45.98