The 11th fallacy: Business Logic can be centralized
- 29 Apr, 2012
Most of the other fallacies of distributed computing are well documented.
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. This 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!” (DRY) and in the other ear “Tight Coupling is bad!” How do we not repeat ourselves and keep a decoupled architecture? If we write it once and only once, we will be coupled to it everywhere it is used. But if we decentralize our rules, we have “repeated ourselves”. How can we resolve such things?
When two principles are pushing in opposite directions, some underlying assumption is wrong. Often the word “the” is the culprit – Udi Dahan
Ah there it is. If loose coupling and DRY are pushing in opposite directions what underlying assumption is wrong?
So what assumption is wrong? In the course, we discuss that there isn’t one view of our architecture (“the architecture”). Instead of trying to centralize business logic with DRY – why not have multiple views of your architecture? If so, we could tag each requirement so that with a GREP query we could easily find everything related to a business rule. Giving credit where due, this idea is attributed 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.
