Eric Evans provides this interesting commentary while he discusses refactoring targets:
When you encounter a large system that is poorly factored, where do you start? In the XP community, the answer tends to be either one of the these:
- Just start anywhere, because it all has to be refactored.
- Start wherever it is hurting. I’ll refactor what I need to in order to get my specific task done.
I don’t hold with either of these. The first is impracticable except in a few projects staffed entirely with top programmers. The second tends to pick around the edges, treating symptoms and ignoring the root causes, shying away from the worst tangles. – Domain Driven Design, Eric Evans
I can think of many times where developers (myself included) have really just been gold plating under the guise of refactoring, or other times when refactoring activities contributed superficial cosmetic changes while the real mess lies beneath – getting to the root of the problem requires significantly more time and work than we’re often allocated and the cosmetic changes give us a sense of motion without moving. Then there are the occasions where seemingly superficial refactorings lead to an insightful break through.
Of course Evans isn’t suggesting that we stop refactoring altogether, instead he suggests that we think about what we’re refactoring, and that we focus on the parts of our software that provide the most value – in the context of Domain Driven Design this would be our Core Domain.
In Domain-Driven Design: Tackling Complexity in the Heart of Software Eric Evans shares his extensive development and consulting experience as he outlines his approach to software development and design using Domain Driven Design (DDD). Evans’ writing style is easy to read as he maintains a comfortable conversational tone while pragmatically guiding us through the many patterns and concepts that encompass DDD. However; be-warned the concepts that lie within are occasionally dense, abstract, but ultimately enlightening as Evans’ forces us to look at development from a new perspective.
It’s also fair to mention that this book has been charged as being just another patterns book, and while I can see this perspective, some of the concepts do come across as being overly abstract without clear implementations (code) to reference, but this books is much more than another patterns book. As a developer you don’t want to overlook this book, it’s an insightful snapshot into the mind of an experienced developer. From my experience the concepts and patterns surrounding Domain Driven Design frequently crop up in Service Orientation, MVC/MVP structured Web Applications, Object Orientation, Test Driven Development, Model Driven Development, and other modern staticly typed best practices. If you do find yourself grasping for more concrete implementations then you’ll want to read Jimmy Nilsson’s Applying Domain-Driven Design and Patterns: With Examples in C# and .NET book too – Nilsson’s book provides many code examples while directly referencing Evan’s text.
I highly recommend this book, it’s a great reference to have alongside Steve McConnell’s Code Complete, Facts and Fallacies of Software Engineering by Robert Glass, and the Martin Fowler blessed books too.
A group of us reread this book as part of The Calgary Book Club. View my review on Amazon.
During our Domain Driven Design (DDD) book club we had the re-occurring discussion over the fallacies of the one-size-fits-all approach. We discussed how DDD is not the solution to every problem – other approaches like the Smart UI Anti-pattern work great for small one-off projects, teams with limited experience, projects under tight time / financial constraints, etc… However; we also postulated that, if your team has past successes with DDD, then they can be just as productive using DDD while gaining the benefits that DDD can provide.
Our postulation wasn’t earth shattering by any means. Basically we were reiterating that: if you already know how to do it right (or at least righter than the alternatives), then do it right the first time. Developing cross browser compatible web sites using web standards jumps to my mind as another example – a cross browser site is trivial if you’ve had a previous success. This idea extends well beyond software. Experienced professionals like Mike Holmes (from the construction industry) runs his organization (Make it Right) on this very idea.
If you’re going to do something, do it right the first time – Mike Holmes