Most developers I know can code an Application in three Layers -as long as those are Persistence, Business and Presentation. I find it very interesting that developers can generally use a Layer but simply can’t apply the underlying technique of Layering. People will use Layers that were created for them in some architectural archetype (like the omnipresent 3-Layer-Architecture of most webapps) but find very hard to Layer their own architectures. I think it may be the odd case of having a lot of practical examples available but not much material on the principles behind those. This post will discuss briefly some interesting aspects of Layering.

Layering is about grouping together elements (objects, components, functions… you name it) based on their responsibilities. In a typical three Layer web application all your HTTP/HTML, MVC and the like will stay at the Presentation Layer. Your business objects will all be grouped in the Business Layer and your database-related code will belong to the Persistence Layer.

Why does this help? I think the main reason is because the technique helps with dependency management. Using Layers you manage coarser-level dependencies: instead of managing it at the element (object, class, etc.) level you manage can “zoom out” and see the big picture easily. It is very hard to know that class ABC232 shouldn’t talk to class XYZ987 if there’s no pattern applied in your dependencies. Take the diagram below as an illustrative example.

By grouping your classes based on the role they play in your system you can see the little “communities” of objects in your architecture. Lower level Layers will often contain basic and technology-related features; upper Layers will have concepts that are less geeky and more related to the business you are modeling. In the picture below, the Layered version of the previous diagram looks a bit more organised.

Having some discipline in dependency management probably makes easier to spot weird relations, like the one highlighted below -that was present in all previous diagrams.

Layering may also help you build better abstractions because often the higher the Layer an element is placed the higher its abstraction level should be. As I said previously, at the very bottom your Layers deal with Computer Science concepts like filesystems, databases, network protocols and the like. They’re often in the bottom Layers because they’re extremely reusable and are not dependent on your application.

Due to the dependency management, changes in Layered software tend to be either Horizontal or Vertical. Vertical Change applies to a more than one Layer and are generally related to changes in features or other functional aspects of systems.

Horizontal Changes are those that affect only one Layer. They’re often related to implementation, technology or strategy changes. If you refactor your domain model or change the persistence engine from plain JDBC to Hibernate that’s very likely to affect only one Layer, an Horizontal Modification.

It is very important to choose the right level of abstraction for each Layer. I like to call the anti-pattern of having wrong abstraction levels in Layers the “Galactic Hitchhiker”, an element or a concept that is not confined to a Layer but spread all over the system. It’s something that happens when you have your Payment object depending on a network socket.

But in the case where the classical Persistence/Business/Presentation won’t work for a given application, which Layers should I have? It’s hard to say. Just like Object-Orientation tells you why and how to organize atomic concepts but not what would be an object, Layering itself won’t help you in it.

You have to find out which components in your system share a common responsibility and how is the dependency flow in it. Remember that Layering, pretty much like any Pattern, is about managing complexity.