Rating: 
Summary: Essential, but oft Neglected Stuff
Review: Developing a language to enable communication between team memembers and with domain experts seems like an obvious thing to do. Most teams do not do this and start their application by solving technology problems. This book describes the utility of a domain-driven approach to building systems and shows you how to apply this approach effectively. This book makes excellent use of patterns to demonstrate how design, architecture and development practices such as continuous integration interact with each other to determine how good your application will be. Like all good patterns books, the information in this book seems obvious once you read it. But it is material most people overlook. Buy this books to understand the value of a domain driven approach, or if you already understand that, use it as a guide for teaching others.
Rating: 
Summary: Essential Knowledge for Designers of Non-trivial Systems
Review: 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.
Rating: 
Summary: Reality Check - Yet Another Patterns Book
Review: 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.
Rating:
Summary: One of the best software books I've read
Review: 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.
Rating:
Summary: Read this book to graduate from programmer to designer
Review: 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.
Rating:
Summary: practical and inspiring
Review: I thoroughly enjoyed Eric's book - a reminder to all of us about the heart of OO design. It is both a vision of how to design with objects, and filled with practical tips for both refactoring towards better models, and creating robust domain layers.
Rating:
Summary: Remarkable advice & approach
Review: 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.
Rating:
Summary: Re-introduces a new way to think about software design
Review: If you have even been involved in a software project (a) as a developer and did not know what the end product is going to be used for or how it will be used or (b) as an architect who spent countless hours with your stakeholders and domain experts trying to figure out how to go about architecting your application, then you should read this book. Read it again after you have read it for the first time. This book is packed with pointers, information, tips, how-tos, "down to earth" practical samples, and even conversational examples that one could have while gathering requirements. Evans in his book fills a wide gap that we all tend to come across while designing software applications. There are many software engineering processes out there, and each one tries to tackle the complexities of designing software applications for a given domain in its own way. Evans recognizes the tools and the processes that are popular in the industry, UML, Agile, and focuses on some aspects of the software engineering process that we tend to miss. He starts the book by talking about the importance of creating and having a Ubiquitous Language. There is a similar concept in the RUP, but not emphasizes as much - or at all. Evans goes into a great detail on why, from the inception of a project, it is important to have a common language and gives many pointers on what makes up the Ubiquitous Language for each project: "Use the model as the backbone of a language. Commit the team to exercising that language relentlessly within the team and the in the code. Use the same language in diagrams, writing, and especially speech." Parts II-IV of the book put domain-driven design in perspective, and show the reader thru examples and patterns, architectural patterns, design patterns and process patterns, the importance of having a consistent model that maps to the domain and how to go about achieving such model. In an essence, "Model-Driven Design discards the dichotomy of analysis model and design to search out a single model that serves both purposes". Part II of the book, introduces the building blocks of a Model-Driven Design. This section, as with the others, takes popular patterns from the Gamma, Flower, or others and applies them to the topic at hand - Model-Driven Design. In that aspect, the reader can easily follow the text and relate to topic at hand. Evans uses the ever-popular Model-View-Controller (MVC) design pattern to get things going in part II. He then goes off to explain why the layered architecture approach is an important aspect of a Domain-Driven Design and how it would makes things simpler: "[Layered Architecture] allows a model to evolve to be rich enough and clear enough to capture essential business knowledge and put it to work." The author then goes into great detail in explaining the elements that express a model:
1)Entities: An object that is tracked thru different states or even across different implementations.
2)Value Objects: An attribute that describes the state of something else.
3)Services: Aspects of domain that are expressed as actions or operations, rather than objects.
4)Packages: Organize the objects and services. What do you want to do after you have designed such elements? The creation and life cycle management of objects are discussed next in this book. Three patterns, mostly from the Gamma book, are used to manage the life cycle of objects:
1)Aggregates.
2)Factories.
3)Repositories. Aggregates represent the hierarchy of objects or services and their interactions. Factories and Repositories operate of Aggregates and encapsulate the complexity of specific life cycle transitions. Part III of the book talks about the things developers and architects need to do to achieve a Supple Design. Refactoring over and over represents the topic in this section: "Each refinement of code and model gives developers a clearer view" The author talks about a breakthrough point during the design that the "designers see the light" and both the domain experts and the designers, after many iterations, have finally come to this higher level of understanding of the domain and the value of refactoring exponentially increases after that. Part IV of this book talks about a very important topic that we all have struggled with one time or another: the ability of the model and the modeling process to scale up to very complicated domains. It is great that we can model a small domain, but one goes about modeling an enterprise, which is most likely, too complex to model as a single unit? Low-coupling and high cohesion still applies here, but the goal is to not loose anything during the integration process. The author goes in to a great detail in this part to emphasize that even in large circumstances such as modeling an enterprise, every decision must have a direct impact on system development. Three different themes are covered in this section in order to assist with modeling of large units:
1)Context: the model has to be logically consistent throughout, without contradictory or overlapping definitions. For this theme, the author introduces the concept of a Bonded Context- a way that relationship to other context are defined a overlapping is then avoided.
2)Distillation: Reducing the clutter and focusing attention appropriately.
3)Large-scale Structure. The concept of Responsibility layers are introduced In summary, Evans did a great job in writing this book, and filling it with useful ways of designing and architecting software applications that target a domain, which in most cases we do not know much about.
Rating:
Summary: Perfect content - but too long for many readers
Review: In Domain-Driven Design, Evans describes a set of patterns that capture exactly what both MDA and AOP attempts to be a solution to. Evans approach is elegant, yet realistic. Unlike other model-focused approaches, he has a good focus on lessons learned from agile software development like extreme programming, and explains how domain modeling fits in with testing-driven development, iterative and incremental development, and refactoring.
I have one big gripe with this book, however. It is too long. Everything in the book is useful to me, but I would like to see more people read the parts of the book that are relevant to them. If the book had a thinner companion version or a reading guide for people who were in a hurry in the introduction it would be perfect. As it is, I cannot recommend it to "coders" or business analysts, only to software architects and modelers.
Rating:
Summary: helps to orgnize
Review: Nice book. Helps to organize my approach to the design issues and create models that can be realized/implemented as much closer to the actual structure of the problem.
| 
