Take a photo of a barcode or cover
4.05 AVERAGE
4.05 AVERAGE
informative
slow-paced
informative
reflective
I’m gonna call it - didn’t read it cover to cover but i got the gist ya know
Initially I decided not to write a review since I found a bunch of people who shared my impressions of the book and whose reviews put those impressions to words in a far more eloquent and analytical manner than I ever could but in the end it feels a shame not to say anything.
All in all, DDD was in many ways a great read, worthy of its highly lauded cult status - the ideas it presented, especially at the time of its writing, were almost groundbreaking. To top it off, the methodology it proposes seems as valid as ever so in that regard it's aged quite well (or our profession hasn't matured enough or maybe a bit of both).
Where it hasn't aged so well is the writing. At times it felt so dry and abstract and repetitive that I had to re-read whole paragraphs when the examples section came around because I've forgotten what the examples were about to demonstrate. I also quickly learned not to bother if I wasn't at the top of my game concentration-wise. While DDD is definitely a complex topic, it definitely isn't more complex than others I've read about but it certainly felt so...
So there it is, my 2¢. You'll excuse the lack of potatoes though.
All in all, DDD was in many ways a great read, worthy of its highly lauded cult status - the ideas it presented, especially at the time of its writing, were almost groundbreaking. To top it off, the methodology it proposes seems as valid as ever so in that regard it's aged quite well (or our profession hasn't matured enough or maybe a bit of both).
Where it hasn't aged so well is the writing. At times it felt so dry and abstract and repetitive that I had to re-read whole paragraphs when the examples section came around because I've forgotten what the examples were about to demonstrate. I also quickly learned not to bother if I wasn't at the top of my game concentration-wise. While DDD is definitely a complex topic, it definitely isn't more complex than others I've read about but it certainly felt so...
So there it is, my 2¢. You'll excuse the lack of potatoes though.
For some reason this book is greatly beloved in programming circles. I can't tell if that's because the people doing the beloving are die-hard Java Enterprise programmers, or if I'm just missing something here. But I think it's the former.
Domain-Driven Design is an excessively dry, boring book whose main thesis seems to be "make sure everybody agrees on what terminology is being used." What could have been this one sentence is instead 650 pages, chocked full of UML diagrams and insipid discussions about shipping containers. And that's saying something, coming from a guy who reads excessively dry boring math and engineering books on the regular.
If I had to be charitable, I would say that this book is independently groping towards functional programming without knowing it, and trying to shoehorn the ideas into an OOP-mindset. There is a lot of potential here for things to like, but it ultimately falls short. If you've only ever coded in Java, or frequently sketch UML diagrams, this might be the book for you. And if so, may god have mercy on your soul.
Domain-Driven Design is an excessively dry, boring book whose main thesis seems to be "make sure everybody agrees on what terminology is being used." What could have been this one sentence is instead 650 pages, chocked full of UML diagrams and insipid discussions about shipping containers. And that's saying something, coming from a guy who reads excessively dry boring math and engineering books on the regular.
If I had to be charitable, I would say that this book is independently groping towards functional programming without knowing it, and trying to shoehorn the ideas into an OOP-mindset. There is a lot of potential here for things to like, but it ultimately falls short. If you've only ever coded in Java, or frequently sketch UML diagrams, this might be the book for you. And if so, may god have mercy on your soul.
Very impressive and thorough book on developing an object model, maintaining it through the development process and driving the development process from the design. Includes using appropriate patterns at the overall design level and has good coverage on potentially sticky topics such as merging and demerging models, resolving incompatibilities between models and architectures, how to partition models to manage complexity, and much more.
It's not perfect - it has a slightly strange relationship with Extreme Programming - sometimes wholeheartedly embracing it, at other times rather backing away from full zeolotry. It includes examples of how XP can resovle some situations which XP is a good match for, but doesn't refer to XP some times in areas which XP finds difficult. It's the areas where the book strays closest to XP that area least convincing, to be honest, but then I'm a sceptic about pure XP.
While recognising the benefit of maintaining a single model, rather than separate analysis and design mdoels, I'm also pretty sceptical about his belief that business analysis is fully in the realm of developers rather than with a business analyst (the book's a little schizophrenic on this - all the examples show developers doing business analysis, but one of the key case studies cited at the end was furthered by a skilled BA). In my experience, the skill sets of programmers and BAs have a lot of cross-over, but they're not the same. Of course, adhering to a hard-core XP viewpoint deprecates extensive up-front analysis and design - I have far more sympathy for the Iconix model, as in "Use Case Driven Object Modeling with UMLTheory and Practice".
I'm also pretty dubious about using UML class models as a communication medium with customers during analysis. While these are to a large extent a similar view to a high-level entity model, I've yet to meet a customer who is comfortable with the notation used in class models, and the example used in this book where aggregations, multiplicity and even some methods are being defined alongside the customer strikes me as very unrealistic. Against that... I'm tempted to give it a try, as I can see benefit in being able to have the customer talk in the same language and have the shared model view as the developers.
Finally, it's a very thorough book, but to be honest it's a bit of a slog as well - it's quite dull & verbose in parts.
Recommended, but with due skepticism towards the hard-core XP aspects.
It's not perfect - it has a slightly strange relationship with Extreme Programming - sometimes wholeheartedly embracing it, at other times rather backing away from full zeolotry. It includes examples of how XP can resovle some situations which XP is a good match for, but doesn't refer to XP some times in areas which XP finds difficult. It's the areas where the book strays closest to XP that area least convincing, to be honest, but then I'm a sceptic about pure XP.
While recognising the benefit of maintaining a single model, rather than separate analysis and design mdoels, I'm also pretty sceptical about his belief that business analysis is fully in the realm of developers rather than with a business analyst (the book's a little schizophrenic on this - all the examples show developers doing business analysis, but one of the key case studies cited at the end was furthered by a skilled BA). In my experience, the skill sets of programmers and BAs have a lot of cross-over, but they're not the same. Of course, adhering to a hard-core XP viewpoint deprecates extensive up-front analysis and design - I have far more sympathy for the Iconix model, as in "Use Case Driven Object Modeling with UMLTheory and Practice".
I'm also pretty dubious about using UML class models as a communication medium with customers during analysis. While these are to a large extent a similar view to a high-level entity model, I've yet to meet a customer who is comfortable with the notation used in class models, and the example used in this book where aggregations, multiplicity and even some methods are being defined alongside the customer strikes me as very unrealistic. Against that... I'm tempted to give it a try, as I can see benefit in being able to have the customer talk in the same language and have the shared model view as the developers.
Finally, it's a very thorough book, but to be honest it's a bit of a slog as well - it's quite dull & verbose in parts.
Recommended, but with due skepticism towards the hard-core XP aspects.
Long (I'm starting to feel that way about all programming books...), but worthwhile. Key takeaways for me:
- If business people use terms that don't appear in your model, that's bad.
- "Make implicit concepts explicit." Important business rules should not be hidden away in conditionals inside an unrelated object.
- Constrain relationships as much as possible. For instance a has_many should only be bidirectional if it is really necessary. A way around it is to use repositories to access the information.
- Responsibility layers can be a good way to structure the model (operations, decision support, policy, potential, etc...)
- "Refactor towards greater insight."
- "Distill the core." Ruthlessly extract generic concepts that aren't essential to the domain.
- If business people use terms that don't appear in your model, that's bad.
- "Make implicit concepts explicit." Important business rules should not be hidden away in conditionals inside an unrelated object.
- Constrain relationships as much as possible. For instance a has_many should only be bidirectional if it is really necessary. A way around it is to use repositories to access the information.
- Responsibility layers can be a good way to structure the model (operations, decision support, policy, potential, etc...)
- "Refactor towards greater insight."
- "Distill the core." Ruthlessly extract generic concepts that aren't essential to the domain.
informative
slow-paced
I love this book so much. This is the book I would hand out to people just starting a job as a programmer. It's especially useful for consultants and programmers on services teams; it tells you how to take a series of meetings and turn them into a common language for talking about domain objects.