Take a photo of a barcode or cover
4.05 AVERAGE
4.05 AVERAGE
When going into this book, many of my peers warned me about how this is a tough read. And how the examples are so far-fetched and hard to understand. How it is a slog to go through.
Well, I'm glad I read it, and I found it to be amazing. The theory provided in the book, spans several different possibilities and is not just based on the happy path of a software project. On top of all that are all the examples on the book to make the theory really come to life.
Granted, some are harder to understand than others, but all of them are integral to the goal of this book.
I'm looking forward to putting all the principles en practices provided by this book to use.
Well, I'm glad I read it, and I found it to be amazing. The theory provided in the book, spans several different possibilities and is not just based on the happy path of a software project. On top of all that are all the examples on the book to make the theory really come to life.
Granted, some are harder to understand than others, but all of them are integral to the goal of this book.
I'm looking forward to putting all the principles en practices provided by this book to use.
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.
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.
Did not make it through, the organization of this book did not flow well for me and I just couldn't pay attention long enough to really get any meaning out of most chapters. Maybe I'll try again if I move into an applied science field, but this book is not targeted towards writing dev tools.
challenging
informative
slow-paced
A must read for every professional software engineer. It’s a difficult book that takes a lot of time and energy to read and fully digest but it is well worth the time. If possible, read and discuss it with other software engineers, to really make the most of it.
Uhh, so I'm pretty sure I didn't understand all the concepts but I'll try to review it anyway. I've wanted to read this as it's one of those few timeless books in CS that occasionally gets mentioned. Domain-Driven Design is sold as a way to produce software that is easy to understand, use, maintain and extend. In essence what you would like your code to look like. Evans has gathered the different principles into a pattern catalog and describes how and when to use the different patterns.
The patterns are massively useful and I can see some that I have used, others I understand and see a use for and yet some others that I'm not sure I'll ever use but it's nice to know about it regardless.
So far so good, my criticism of this book would be that it's too theoretical and abstract and at the same time really specific. Most of the book is abstract in the sense that I'm sometimes not sure whether it's still about code or just general work of some sort. I think Evans tries to decouple the technical details from the Domain-Driven design but it makes it harder for me to fully comprehend and read the book. Most of the examples seem like they're under heavy NDA from the companies where Evans has helped as they are sometimes vague which made me struggle to understand. For a book that emphasizes domain knowledge, the examples didn't quite explain the domain knowledge well enough for me.
Sometimes Evans has code snippets which is easier for me to read and understand and the code snippets are fine in that they don't use some fancy paradigm but the object-oriented paradigm. These snippets help a lot in comprehension. What doesn't help comprehension is the weird mentions of beans in Java which is just a bit weird as it's such a detailed language specific thing to mention.
Overall it's worth reading and I feel there's plenty to take away from. It's one of those books where new insights come every time it is read and I'm sure on my next read in a couple of years, more of the concepts will start making sense.
The patterns are massively useful and I can see some that I have used, others I understand and see a use for and yet some others that I'm not sure I'll ever use but it's nice to know about it regardless.
So far so good, my criticism of this book would be that it's too theoretical and abstract and at the same time really specific. Most of the book is abstract in the sense that I'm sometimes not sure whether it's still about code or just general work of some sort. I think Evans tries to decouple the technical details from the Domain-Driven design but it makes it harder for me to fully comprehend and read the book. Most of the examples seem like they're under heavy NDA from the companies where Evans has helped as they are sometimes vague which made me struggle to understand. For a book that emphasizes domain knowledge, the examples didn't quite explain the domain knowledge well enough for me.
Sometimes Evans has code snippets which is easier for me to read and understand and the code snippets are fine in that they don't use some fancy paradigm but the object-oriented paradigm. These snippets help a lot in comprehension. What doesn't help comprehension is the weird mentions of beans in Java which is just a bit weird as it's such a detailed language specific thing to mention.
Overall it's worth reading and I feel there's plenty to take away from. It's one of those books where new insights come every time it is read and I'm sure on my next read in a couple of years, more of the concepts will start making sense.
informative
sad
slow-paced
There is value in it for sure. Evans shares knowledge that is useful and often applied in the software world. And I agree that as programmer you should at least skim it.
But his writing style is the slowest and dryest I've ever encountered. It reminds me of the time when I was writing research papers that didn't have enough content and I needed to stretch the word count so I started adding meaningless words to blow it up.
Sometimes I summarized whole pages of this book just by writing down two sentences and I'm sure that containend all the relevant information.
My favorite quote "... write just a very short document of brief 3-7 pages." This is how brief the whole book feels.
But his writing style is the slowest and dryest I've ever encountered. It reminds me of the time when I was writing research papers that didn't have enough content and I needed to stretch the word count so I started adding meaningless words to blow it up.
Sometimes I summarized whole pages of this book just by writing down two sentences and I'm sure that containend all the relevant information.
My favorite quote "... write just a very short document of brief 3-7 pages." This is how brief the whole book feels.
A classic, and one that I enjoyed reading even as I found it dense and hard to read quickly.
This book is best if you already have (at least) a few years of experience in an object-oriented language, as well as experience with agile and large projects. Design is important for the success of any project, but it's especially important when there are multiple teams. If you're working on a small project (fewer than 25 people) or are new to the industry, I think it's more important to be familiar with your programming language and your frequently-used libraries.
I think it's amazing that the insights in this book are embedded into a library that I use at work every day (and mostly take for granted). This book is over 15 years old, and will likely continue to be read for many years to come.
This book is best if you already have (at least) a few years of experience in an object-oriented language, as well as experience with agile and large projects. Design is important for the success of any project, but it's especially important when there are multiple teams. If you're working on a small project (fewer than 25 people) or are new to the industry, I think it's more important to be familiar with your programming language and your frequently-used libraries.
I think it's amazing that the insights in this book are embedded into a library that I use at work every day (and mostly take for granted). This book is over 15 years old, and will likely continue to be read for many years to come.
This book is impossible to rate.
The ideas in this book are incredibly useful, and I am grateful to the author for sharing them with the software development community. In this perspective, not reading this book borders on professional negligence.
Unfortunately, I find the writing practically impenetrable. There are so many quaint and opaque verbs and adjectives that never get defined or even justified. Does "tightening" make a model "richer" and/or "deeper"? What about "enriching"? Is either one distinct from "distilling"? Is a "sharp" design always "supple" and vice versa? Could you "sharpen" a model too, or does it only apply to designs? What is it about the nature of domains that makes "carve off" a suitable description of what you do when you separate out a subdomain? What does it mean for knowledge to be "crunched"? There are so many vague terms, so many implied metaphors! Why? I am convinced that it would be possible to present these terrific ideas in a much more -ah- "distilled" form. With a "tighter" vocabulary. As it is, I am using a high-concentrate mixture of willpower and espressos to force my way through because I need the insights buried underneath the text.
The book also suffers from poor editing. There is quite a bit of redundancy, and some discussions lack focus. Many of the introductions or summaries to chapters could have been cut in their entirety. I've even found the same sentence repeated just a few paragraphs apart - something that just a single alert proofreader capable of focusing throughout the text should have caught. But it *is* hard to keep that focus.
It is a crying shame, since the underlying ideas and intentions are so good.
The ideas in this book are incredibly useful, and I am grateful to the author for sharing them with the software development community. In this perspective, not reading this book borders on professional negligence.
Unfortunately, I find the writing practically impenetrable. There are so many quaint and opaque verbs and adjectives that never get defined or even justified. Does "tightening" make a model "richer" and/or "deeper"? What about "enriching"? Is either one distinct from "distilling"? Is a "sharp" design always "supple" and vice versa? Could you "sharpen" a model too, or does it only apply to designs? What is it about the nature of domains that makes "carve off" a suitable description of what you do when you separate out a subdomain? What does it mean for knowledge to be "crunched"? There are so many vague terms, so many implied metaphors! Why? I am convinced that it would be possible to present these terrific ideas in a much more -ah- "distilled" form. With a "tighter" vocabulary. As it is, I am using a high-concentrate mixture of willpower and espressos to force my way through because I need the insights buried underneath the text.
The book also suffers from poor editing. There is quite a bit of redundancy, and some discussions lack focus. Many of the introductions or summaries to chapters could have been cut in their entirety. I've even found the same sentence repeated just a few paragraphs apart - something that just a single alert proofreader capable of focusing throughout the text should have caught. But it *is* hard to keep that focus.
It is a crying shame, since the underlying ideas and intentions are so good.
This book is a classic; I just had to read it. It contains invaluable knowledge for every developer that has to tackle complex systems. Many of the patterns described in this book have now become mainstream.
Unfortunately, though, I found this book very difficult to read. It is big and verbose. I often found it boring. I prefer concise, straight-to-the-point writing. The material is great and important, but the writing was not to my taste. I'm still glad I read it though.
Unfortunately, though, I found this book very difficult to read. It is big and verbose. I often found it boring. I prefer concise, straight-to-the-point writing. The material is great and important, but the writing was not to my taste. I'm still glad I read it though.