I listened to a recent .Net Rocks podcast about Domain Driven Design. Now, despite reminding me of a post last week by Secret Geek about how everything is driving design these days, I think a lot of what was said makes sense to me. Eric Evans' point on the podcast seemed to revolve around learning a given domain and letting experience with the domain drive development decisions.
From the contents of his book at Amazon, it looks like Eric's idea is a modification or extension of Model Driven Design—i.e. an attempt to unify development efforts within a descriptive framework approachable by non-technical entities. In this case, letting the needs of the domain determine the focus of development. For example, he talked near the end about how it is often more valuable to leave legacy code alone (maybe wrapping it with a translation layer) in order to spend resources on the things that will provide better value than you can achieve by replacing the legacy application.
Good Enough
Eric also used a phrase that I listen for as a flag that identifies someone to take seriously: "good enough". Good enough is a phrase used by people who are actually trying to apply YAGNI as more than a way to win an argument. Good enough is a limiting term, a cut-off, a phrase that gets you from the isolation of the silicon tower to actually developing software.
Now, I have to be careful here because "good enough" is also useful for burying dangerous assumptions. I think that Eric is an example because he never elaborates on what something is good enough for. Given that he's explaining Domain-Driven Design, you could assume he's saying that it's good enough for the domain, but that doesn't map. Nobody works for a domain.
Pandering to Business Managers
Which got me thinking. Eric is talking about developers and domain experts creating a common framework for communication, but really, starting at the domain elides over the most important consideration in software development: the business. The context for "good enough" should be rooted in tangible benefit for your company.
Naturally, I thought I would be all clever-like and create another "driven". Unfortunately, IBM already mucked this one up. In what looks like naked pandering to clueless business managers, IBM proposed "Business-Driven Development" in December of 2005. I mean, can you take any paper seriously that contains this quote:
The inherent problem with the enterprise software development process is that it suffers from a lack of agility to match the pace at which the business needs to change in order to keep up with the market trends and competition.
Now, you could make a case for market trends and competition being pretty malleable—even to the point of outpacing the ability of software development to keep up—but that's kind of beside the point. The fact of the matter is that of all the things a business needs to change to adopt a new business process, software is the most adaptable.
Functionally, IBM's proposal is a way to isolate software development and assert management control. Under scrutiny, it looks to me like an attempt to force agile iterative principles into a BDUF format that IBM's Rational products can actually handle.
Dollar-Driven Development
What I'd like to see is Eric's domain drivers better focused as a responsibility towards whoever is underwriting development. This is hard to name because his principles are broadly applicable for business, government or even open source.
Still, somebody is fiscally responsible for software development and it is that responsibility that should drive development decisions--i.e. the best interests of the entity underwriting it. For open source projects, that would be the interests of the benevolent dictator in charge. For business development, that would be the best interest of the business you work for.
This is easier said than done. In order to work for something's best interest, you really have to know its interests well. I think that may be the heart of what Eric was saying about learning the concerns of a domain and letting those concerns drive development. It means developing expertise in a domain that may or may not be of your choosing. This takes time, effort, and access to domain experts. It means delving deeply into the reasons things are done now and the problems current processes were meant to solve.
Mainly, it means learning about things that aren't computers and likely have nothing to do with them. Whether it's a bank, talent agency, or bail-bondsman, it's not going to be something that you learned in school. It's yet another thing you have to learn on top of all the technology stuff that keeps changing.
Good thing you're good at learning things. Right?