The reference on domain-driven design. A good book, but at times difficult to read and really get involved in. Takes a very high-level approach to design and doesn't discuss some implementation details of going down the domain model path. It took me some time to get through this book.

While this book is useful in reflecting concepts, some chapters are too wordy. There's something to learn for every OO software developer or designer. However, at times it feels like you're attending a lecture of a very knowledgeable and experience teacher who sometimes struggle to deliver his knowledge, jumping and skipping in his explanation which loses audience concentration and requires reading it again.
This book gives you a feeling of a well done research with author proving his ability to go long and playing around the topic.
Would be a good book to be discussed in class.

This book is the bible of domain modeling. This is a must read for any architect or developer that has to provide solutions for complex domains. The examples in this book are real-world, make sense, and are applicable to solving any business problem. The only wish I have is that I haven't read this book years ago.

I have to admit - I struggled with this book - a lot. Usually, I can read a text, take a key idea and without too much difficulty, find someone else who could benefit from the same idea. My problem was who to share this book with? This is definitely not beginner or intermediate material. I constantly wished I had a mentor to explain some of the key ideas.

If this was a college course I would highly recommend it. If the author had a training session I would go. My problem was I either understood the example and missed the solution or got the solution and totally could not grasp the example. There is a lot of good information here but I was left bewildered and lost far too often especially in the later parts of the book.

With that being said, I did pull a number of good ideas from the material. The author spends a lot of time stressing the importance of a clear, common language set and how language can drive the domain model. He has a different viewpoint on layering the various aspects of the application. There were a lot of small ideas, especially in the first half that I really enjoyed.

I think I will put this book on the shelf for now. In a year or so I'll pull it down and see what I can grasp from it a second time. I am not so sure that this is written for the developer of small one-off applications. I think it is written with larger projects and groups in mind. I am sure that there is value here that many people could take advantage of.

This book gets longwinded and could have shed about 250 pages on the backend. However, I would recommend the first 200+ pages to every OO developer who is laboring with domain experts, stakeholders and users to match their requirements up with an object model. Like most development books I can't recommend everything the author writes, but that said I think this book's main message is very solid and offers plenty of good ideas to the OO developer writing common business applications.

unlike many other books focusing on how to use a technology, or illustrating what is basic OO concept, this book focus on how to analyze and solve day-to-day application design issue. It has summed up many best practice and distill them into more concise and easy to understand building block abstraction. The style of writing is very easy to follow. It also makes me interested and want to read more, unlike other dry-reading book that make me sleep. I highly recommend this to anyone who is interested in making a coherent and maintainable design for large system.

I just finished reading this book by Eric Evans on "Tackling Complexity in the Heart of Software." Domain Driven Design should really be required reading in college, in my opinion. Eric Evans has a way of describing benefits of rich modeling techniques and how to develop them. He guides you through learning to develop the ubiquitous language of the domain, an important concept for effective modeling. He also addresses many common concerns such as scalability with the techniques in the book.

This isn't your typical software book, chock full of simple examples to help make the author's point. Evans goes into enourmous detail on the examples and builds on them throughout the course of the book. The quality of the examples are what pushes the reader's understanding of the topic to a level that words cannot do alone.

Evans tends to be a bit wordy in this book, and you'll often find that he seems to be repeating himself, frequently with the same verbage. While it can be redundant, the message is important, worth visiting more than once.

Domain Driven Design is among the most profound, impacting, and inspiring software books I have ever read. I give it a 5/5.

I must admit, I haven't finished the book. I find it nearly unreadable. There might be some crumbs of useful wisdom, but the boredom reading the book sent any brain cells to sleep that could absorb that wisdom. If the book would be condensed to - say -- 250 pages, it might be useful (did anyone edit the book?).

I really must admit that I envy people who had the time, energy and concentration to finish the book.

This book is good for small projects and small teams, or for using the techniques found in it for module level analysis. The author attempts to apply his thoughts to large projects, but they would be extremely hard to apply or pull off. He has some great thoughts on how to absorb domain knowledge, but goes over board bashing the Unified Process and other proven techniques. He isn't coming up with anything new, but he does do an excellent job of creating a book. It is very well organized. BTW, if I thought that XP could be pulled off anywhere in the world, with any group of programmers, this book would get a 10+ rating. I think XP works but only in very specific environments. Most environments do not allow for an enterprise level effort of XP.

Domain Driven Design is the perfect compliment to any development shop that has decided to use the agile process of eXtreme Programming. It is centered around iterative coding practices and test driven development but also hints to deeper point where you drive to your user stories in a common language with your consumer. Eric Evans creates a system to drive to a "ubiquitous language", reach deep architectural insight, and create robust systems in a changing environment and he explains all these steps in simple ways.

Where I think this book tends to fall a little flat is that is trying to be everything to everybody. This book is definitely not for the "architect" as these concepts are things that you have learned by fire when fighting the battles against scope creep and communicating with Marketing teams and consumers. This also would be wasted on any fresh developer as many of the things that are discussed have not been experienced yet. I do recommend this book to software developers that have roughly 2 to 4 years of experience as it really does plainly put forth the problem sets and offers a solution that can work in many environments.

This book is fantastic, a great resource and an excellent reference. To abstract and distill a business domain goes beyond implementing every single requirement, it goes deeper and yields better results for the organization, Eric Evans captures this hard-to-teach process and lays it out in clear text. In short, I highly recommend it for any developer, technical lead or architect's book shelf.

A lot has been written about technical frameworks, patterns and implementations, but none tackled this complex topic in such detail before. This book is very dense and written with great care, insight and logical structure. Sometimes, I felt like the author can read my mind: I was reading a chapter and thought: "Fine, this looks good in theory, but what's a good way to apply it?", and promptly the text was folled by an example. In a lot of cases those are not fabricated, but taken from his extensive experience. One can see why it took the author over 4 years to write the manuscript.

I am not only writing from reading the book, as a principal engineer and architect I actually applied the knowledge I solified and gained through the book to a medium-sized project. My expectations were rather modest given my inexperience with domain modelling. However, the project was hugely successful. I attribute that to the very logical layout of the book. I had no problem organizing and memorizing the vast knowledge of 500 dense pages, so it can be applied successfully. I suggested that all of my developers are going to read the book, so we can have a UBIQUITOUS LANGUAGE about the domain of domain modelling.

I was especially pleased with the testability of the domain model. We started programming the model very early in the modelling phase, but because no frameworks or libraries were involved, it was easy to test. In addition we developed scenarios to prove the validity of the model (and how it can meet certain business requirements) and attain feedback from the domain experts.

The only negative point I have to make about this approach is that it requires the willingness of the clients or users to think about their business processes and have the intelligence to explain them. I know this seems silly, but I have dealt with users that want a system to automate their processes, but then refuse or are relunctant to talk or think about it. Most of them I could convince of the value and after a few weeks they finally realized: wow, this is really cool, I actually understand, what those folks are doing, I am involved and they seem to understand me, too. I would call that a break-through.

To sum up, software development with my guidance was always going in that direction, but I never managed to write it down nor explain exactly what I was doing. Eric Evans has a very clear style of explaining this rather fuzzy area of domain exploration, distillation and modelling. It helped me a lot.

One of the first books I've come across that tries to tackle the complexities and problems of our industry pragmatically at the analysis - design level. Great retrospection on the state and afflictions of our industry, while pointing at possible solutions to be matured upon with experience and experimentation.
Great book.

As a developer it is quite easy to take the requirements, do some design and go off and code and come back with a product only to find out later, that the customer really did not want the developer's interpretation of the requirements. This book is more than a reminder of this notion, but also lays out some examples of real experiences of deriving the model. Software engineering is one of those areas that require the trade of knowing the technical development skills and also acquiring great understanding of the domain to be abstracted, developed and made into something computerwise tangent. This is a great book for developers, business analysts, project managers, and anyone in the software business. While others may not regard this book as one of the classics, I find this book an important reminder lest we forget why we are developing the software and the perspective to take while working with the customer.
Thank you, Eric for such a work.

Evans makes an excellent summary of the domain (or information) specific views on software development. Many of the ideas presented have been around for some years, but this seems to be the first book covering all the problems attached to RUP and its process (or use-case) driven approach. I think this book will be the bible for many software developers over the coming five years!

Have to admit right from the start, i'm just about 1/3 through.
However, what I've seen so far is:
1) Lots of reiterations of previously made points.
2) Failing to engage - you will need all the concentration you can muster, which combined with (1) is constantly frustrating.
3) As strange as it may sound - quite Java-oriented. Others may argue with that, but in lots of other environments it's just not going to be practical.

As someone pointed out in Fowler's Enterprise Patterns review, frameworks place restrictions on what patterns you can use or penalize (time-wise) if you force your way. And this book is about the process and the patterns.

Revised:
I've had time to see for myself how little some experienced developers, architects and business analysts value the domain modelling and the development process.

The writing of the book might be imperfect but the material is essential.

This book has subtly but deeply influenced the way I think about software projects. One of the key concepts is 'ubiqitous language'-- basically making sure that everyone involved with modeling the domain uses the same vocabulary-- and now I find myself feeling much more justified in pushing for this in meetings. That's the really great thing about these types of books, if you ask me. Like Martin Fowler's 'Refactoring', DDD codifies a lot of what an experienced developer already knows and does...The key is the codification, which provides much-needed legitimacy in the case of domain modeling, which is often trumped by technology obsession in our industry.

I give this 4 stars instead of 5 only because I prefer a more industry-oriented, less academic style -- that of Ted Neward, for example. I get the feeling Evans, like Fowler, is trying to rise above the practical level to something more general and permanent, but personally I like things in the "ubiqitous language" of enterprise Java as I'm practicing it today.

Really like this book, and have added it to my essential reading list.

Many of the underlying essential techniques for structuring models are described in a fair amount of detail in the book "Objects, Components, and Frameworks with UML: The Catalysis Approach". In addition that work adds the dimension of "refinement" which is a very useful tool in your domain-driven design toolbox.

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.

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.

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.

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.

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.

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.

Alex

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.

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 :-)

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!

This is one of the few books that has seriously changed my perspective on Software Design. I used to fall into the trap of applying technology to the solution, an technique he quietly rebuked and showed the solution.

I'm not totally sure that beginning software professionals would understand what is being said in the book. It seems a bit subtle to me. For me, the revelations came out of experience coupled with the text. Nonetheless, it is written in such a way that it makes you think: and then the resulting revelation is your own.

In short, it caused me to rethink my current projects that I'm working on and seriously changed their scope.