Sign in with Facebook
Einar's Reviews > Domain-Driven Design: Tackling Complexity in the Heart of Software
Domain-Driven Design: Tackling Complexity in the Heart of Software
by
by
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.
Sign into Goodreads to see if any of your friends have read
Domain-Driven Design.
Sign In »
Reading Progress
Comments Showing 1-5 of 5 (5 new)
date
newest »
newest »
I planned on writing my own review but man, have you summed it all up greatly!
Agreed, the writing is a trainwreck from hell, with some good and decent ideas buried by a wordy, arrogant person who thinks his every thought is worth sharing
I totally agree - I've essentially said many of the same things. While there are very good design ideas here, it really could've benefited from better editing. Some of the practical examples are helpful. But when the author talks more abstract, the meaning of it all can be very muddy and obscure.
Also author does not clearly define even the most central concepts like model (however you can check those in the glossary in the end of the book). But the ideas hidden in the book are definitely worth looking for them.