:::: MENU ::::

Why the Layered Architecture Sucks

       We’ve all seen the traditional representation of a Layered Architecture. Sometimes this is what we think of when someone says “Database Application“. Here’s a picture:LayeredArchitecture

The arrows represent dependencies.

Here, the presentation layer depends on the business layer. I like to think of it as “knows exists”. The business layer, knows the database exists. By extension, if a change is made to one part of a system, there may need to be changes made to parts that depend on it.The reason the layered architecture sucks, is because of the dependencies (more specifically, the inevitable discontinuity between the design, and reality).

The dependencies

First, the business logic depends on the representation of the data in the database (or data layer). This is bad, because the business logic needs the relational information, with the representation of the data being the same for both layers, a relation-storage of the data is encouraged by the architecture. NoSQL, (or something else) feels like a strange fit.

Next, the Presentation layer depends on the representation of the data in the database (indirectly, or transitively, or vicariously, or whatever). When I change how my data is stored, I might have to update a REST controller way up front? That seems odd.

Finally, there are implicit dependencies: the data layer will always implicitly depend on the business logic. When a new feature is added, (e.g. a customer can now have multiple phone numbers, or we decide to keep track of spouses and siblings for emergency contacts) there is new information that has to be represented in the data layer.

Changes to business logic may result in changes to what data is stored.  The process to make an update like this, involves first finding where the code needs to change and getting a feel for the type of data it needs, then following the dependencies down to a DAO (or database schema), updating that, then making updates back up the dependency chain to where you started.  In the best case scenario, this change won’t break any other code that may explicitly or implicitly depend on that change to the data layer.(Note: the presentation layer would obviously change from this type of change to the business layer, even in the Layered Architecture this is an explicit dependency)

The data layer will always depend on the business layer; Not recognizing this explicitly when designing a system is setting ourselves up for failure.

Adding the transitive dependency of the presentation layer on the data layer, and the implicit dependency of the data layer on the business layer, a true representation of the Layered Architecture would look more like this:

RealLayeredArchitecture

With this architecture, the easiest (not that it’s easy), but easiest portion of code to swap out would be in the presentation layer, because there is no other code that depends on it. And the hardest (possibly not even practical to do) portion of the code to modify would be in he data layer, because changes may need to be made throughout the business logic, and the presentation layer (obviously it’s hard to re-write our business logic, it’s kind-of everything we do).

In my next post, I’ll describe a better option (a more honest option). Maybe an architecture that can actually be created.


2 Comments

  • Reply Peter Ritchie |

    I think you’ve confused Layered Achitecture with MVC. In MVC The View depends on the Model and the Controller then the Model and the Controller depend on one another (depending on the flavor of MVC). In the MVC pattern, all three are within the UI layer in the layered architecture you describe. Use of the “Business” layer would be encapsulated within the Model, and neither the View nor the Controller would use that layer. Then, of course, the “Business” layer would communicate with the Data layer.

    • Reply shostler@gmail.com |

      Thanks Peter. That’s a really good way to look at it. I was originally trying make a boiled down version of the diagram we commonly see as a stack with 3 to 5 layers with all dependencies in a chain pointing down to “data”. But re-reading this a year later with MVC in mind, I do kind of regret the names of the layers. Good food for thought, I may have to re-visit this. Thanks.

So, what do you think ?