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?

enter image description here


I christen this anti-pattern "The Garlic Architecture"

  • While 19 KLOC isn't trivial, at least it isn't 500 KLOC. – Dan Pichelman Mar 6 '15 at 18:15
  • 2
    SRP is for classes, not for layers. – Doc Brown Mar 6 '15 at 18:20
  • @DanPichelman, yeah no kidding. Better to refactor earlier than later. I literally have done this on four projects now and stall out at about 15k lines each time, and never had an inkling why, until now. – toddmo Mar 6 '15 at 18:21
  • @DocBrown, Hi Doc, good to see you again. What's wrong with this picture? Does it strike you in any way? – toddmo Mar 6 '15 at 18:22

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:

enter image description here

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.