The last three fallacies were penned by Ted Neward of both Java and .NET fame. The first two can be found in his magnum opus Effective Enterprise Java, and the last in a blog post lamenting that he wished it had made the book. The very last one is of particular interest because it is the most controversial: Business Logic Can and Should be Centralized.
When Ted discussed the 11th fallacy, he’s talking about the fact that business logic is going to necessarily be distributed in a distributed system – that we will need to enforce the same rules on clients, on servers, in databases. As Ted states, this is a hard one to swallow, because we believe in DRY (Don’t repeat yourself). We want to write per the Once and Only Once Rule. We feel like bad programmers when we repeat ourselves.
What do we do when in one ear the Pragmatic Programmers are whispering “don’t repeat yourself!” and in the other ear “Coupling is bad!” How do we not repeat ourselves and keep a decoupled architecture? If we write it only once, we will be coupled to it everywhere it is used. But decentralize our rules, we have repeated ourselves. How can we resolve such things?
Udi has a quote I feel is brilliant.
When two principles are pushing in opposite directions, some underlying assumption is wrong. Often the word the is the culprit – Udi Dahan
If loose coupling and DRY are pushing in opposite directions what assumption is wrong?
At this point we have to ask – why are we are striving for DRY in business rules anyway (aside from the fact some old guys with beards told us it was the right thing to do)? Udi points out it’s not making changes in repeated code that is hard, it’s finding all the places where changes need to be made!
So what assumption is wrong? Where is the word “the” causing us pain? Udi offers that we have one “the view” of an architecture. Instead of trying to centralize business logic with DRY – why not have multiple views of your architecture? What if we tagged each requirement so that with a simple GREP query we could easily find everything related to a business rule and make a code change? Giving credit where due, Udi attributes this idea to Philip Kruchten’s paper Architectural Blueprints—The “4+1” View Model of Software.
Does this smack at the extreme programming view that “the code” is the only model? Possibly. I defer the reader to Eric Evan’s work in Domain Driven Design where he says “Documents should work for a living.” I can’t think of a better way for user stories / requirements to stay alive and relevant than to have them cross reference directly with the actual code that implements them in a “requirement view” of our architecture.