Unbeknownst to me while I was building it, I built a “pyramid” architecture. I did not realize this until I laid it out in my new Visual Studio 2013 Layer Diagrammer. Each layer depends on the layer below, and all the other layers below that.
I suspect this is the cause of some of my woes. Each higher layer violates the SRP, because it has more than one reason to change, right? It has multiple contracts with multiple foundational layers. If any of those layers changes, the component has to change.
My question is, how can I refactor this? It’s 19,000 lines of code but I can refactor it given enough time as long as I have a solid refactoring strategy.
And as a side note, I also invite your speculation as to why I felt the need to create it like this in the first place. Is this an anti-pattern? Does it have a name?
EDIT
I christen this anti-pattern “The Garlic Architecture”
14
Based on the picture you provided, this looks like Onion Architecture, but with the dependencies proceeding in reverse.
A typical onion architecture looks something like this:
Each layer presents interfaces (an API) to the layer above it, and communicates with the layer above it, and the layer below it. The onion model has some similarities to a Model-View-Controller architecture or a three-tier architecture, though note the inclusion of a Tests layer, an Infrastructure layer, and an “Inverter.” The Domain Model communicates with a database (normally shown as a component external to this diagram).
The consultant from whom I borrowed this picture describes it like this:
For web-based enterprise applications, we espouse the benefits of a specialized hexagonal architecture known as Onion Architecture. The core principle of this architecture is to build the application around an independent object model that describes the business domain. Component coupling is unidirectional toward the center with separation between component contracts (interfaces) and implementations.
Understanding the structure of the architecture is simple. In practice, the architecture relies on the Dependency Inversion (DI) principle to assemble the components at runtime. We isolate the “Inverter” into a separate physical tier to avoid leaking responsibilities.
0