Take a photo of a barcode or cover
stevex 's review for:
Domain-Driven Design: Tackling Complexity in the Heart of Software
by Ross Venables, Eric Evans
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.