Prone to Shortcuts
Understand the limitations of conventional layered architecture, focusing on how shortcuts and flexible layer access lead to increased technical debt and testing challenges. Learn why pushing components down layers becomes common over time and why strict architecture rules are necessary to maintain clean code.
We'll cover the following...
Global rule in a layered architecture
In a conventional layered architecture, the only global rule is that from a certain layer, we can only access components in the same layer or a layer below.
There may be other rules that a development team has agreed upon, and some of them might even be enforced by tooling, but the layered architecture style itself does not impose those rules on us.
So, if we need access to a certain component in a layer above ours, we can just push the component down a layer and we will be allowed to access it. Problem solved.
Doing this once may be alright. But doing it once opens the door for doing it a second time. And if someone else was allowed to do it, so am I, right?
I’m not saying that as developers, we take such shortcuts lightly. But if there is an option to do something, someone will do it, especially in response to a looming deadline. And if something has been done before, the likelihood of someone doing it again will increase drastically. This is a psychological effect called the “Broken Windows Theory” — more on this in the chapter “Taking Shortcuts Consciously”.
Fat persistence layer
Over years of development and maintenance of a software project, the persistence layer may very well end up becoming something similar to what is shown in the figure.
The persistence layer (or in more generic terms, the bottom-most layer) will grow fat as we push components down through the layers. Perfect candidates for this are helper or utility components since they don’t seem to belong to any specific layer.
So, if we want to disable the “shortcut mode” for our architecture, layers are not the best option, at least not without enforcing some kind of additional architecture rules. And with “enforce”, I don’t mean a senior developer doing code reviews but rules that make the build fail when they’re broken.