A layered architecture style is one where the presentation, business and persistence layers are bundled into one deployment unit. In this article I’ll discuss what it is, and point out the situations where you would choose to adopt it.
This is one of a series of articles where I am going to discuss each of these architecture styles: Layered, Microservices, Pipeline, Microkernel, Service-Based, Event-Driven, Space-Based, and Orchestration-Driven Service-Oriented Architecture (SOA). I’ll provide some insights based on my experiences, and I’ll mention some of the Java / JVM frameworks that support the style we’re talking about.
About Architecture Styles
I recently read the book Fundamentals of Software Architecture: An Engineering Approach. Authors Neal Ford and Mark Richards do a masterful job of summarizing the various styles. They pulled together what I have learned over my many years of designing and developing software. For each style they provide a deep dive into it, explaining the variations and the situations where you may want to consider them.
Any system you design will have a number of architecture characteristics. You may know them as non-functional requirements or quality attributes. Fundamentals of Software Architecture eschews the former as it sounds less important, and the latter implies building them in after the product is created. I tend to agree, so we’ll use architecture characteristics going forward.
Architecture characteristics are the “-ilities” that arise from the discovery and elaboration process. Although they may not come up as explicit requirements from the business users, they nevertheless have an influence on your choice of architecture:
- Scalability
- Elasticity
- Reliability
- Recoverability
- Robustness
- Customizable
- Availability
- Deployability
- Performance
- Usability
- Security
- Simplicity
During your discovery process (also known as requirements gathering), a subset of these characteristics will come out of discussions you have with your business customers. It is this subset that will drive your choice of architecture style.
There Are No Wrong Answers
Don’t we all wish that was the case when we were going through elementary school!
The ever-present answer to the question “What is the right architecture to use?” is “It depends”. It depends on the context you are working in, the set of constraints you are given, and which architecture characteristics come out as important.
Whatever style you decide on will be a trade-off. It will be a compromise between the pros and cons that you evaluated. It will be an acceptance of the downsides because in your judgement the benefits outweigh the drawbacks. As Ford and Richards so aptly put it: “There are no bad trade-offs, only expensive ones”.
What Is The Layered Architecture Style?
Presentation, business and persistence layers: these are what define a layered architecture. Commonly known as a monolith, this style is a single deployment artifact that has several discrete business functions in it, along with the user interface screens used to interact with it. It usually talks to a database that is managed separately. Changes to one function in the monolith usually mean a full regression test of the entire application before deploying it to production.
The term “monolith” has become almost a pejorative in recent years with the rise of microservices and their attending publicity. The thing about monoliths is, they are cheap to build and deploy, relatively speaking of course. But it means you don’t need a highly automated deployment pipeline. You don’t need a sophisticated monitoring or auto-scaling infrastructure. You don’t have the complexities of microservice to microservice communication. If your software engineering processes are not as strong as you’d like them to be, that’s OK.
All this is good until the application grows in size and complexity. The you’ll feel the burden of managing all the different business functions in it. It will take longer to respond to business changes in part because the regression testing effort grows. Deployability suffers because of the growing time, effort and risk to deploy to production.
When to Choose the Layered Style
A layered architecture style is a good choice if simplicity is important. If time is tight and you need to get something out the door for feedback, then this style is suitable. Moreover, it’s quicker to develop in part because the concept of Model-View-Controller is so well known among developers.
Layered Caveats
Small and simple applications often grow in size and complexity. If your monolith is meeting a business need exceptionally well, look forward to more enhancement requests and other changes. All this might be cause for adopting a different, more modular architecture style in the future. Prepare your team for this by ensuring there is clear separation between presentation, business, service, and persistence layers. Arrange your package naming convention so they reflect the business use cases. This takes strong team discipline and a good architect to lead them.
Java Frameworks That Support a Layered Architecture
- Spring MVC. Very popular, due in large part to the smooth integration with Spring’s dependency injection framework and the other Spring libraries such as Spring Security.
- Apache Struts. It’s been around in various forms for years. Still under active development.
- Play Framework.
- Grails. Based on Groovy and incorporates Spring Framework. I used this several years ago (v2.x), but ran into grief when version 3 came out with so many breaking changes. Its tight coupling to a specific version of Java didn’t help. But Grails 4.x.x is the latest major version, so it may be worth another look.
In Summary
Cheap, low and steady volume, infrequent deployments, get something out soon. These are the situations where a Layered Architecture Style would be a worthwhile consideration.
In a future article I’ll use the same lens to examine the microservices architectural style.
