DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Data Engineering
  3. Databases
  4. Layered Architecture Is Good

Layered Architecture Is Good

Layered Architecture is about organizing code for separation of concerns and nothing else. See what it implies for a project like Spring Pet Clinic.

Grzegorz Ziemoński user avatar by
Grzegorz Ziemoński
·
Feb. 13, 17 · Opinion
Like (45)
Save
Tweet
Share
132.27K Views

Join the DZone community and get the full member experience.

Join For Free

Darek, the guy who reviews almost all Tidy Java posts before they are published, suggested that I could do a series on implementing different architectural styles — their pros, cons, etc. I decided to give it a try, and here comes the first one – Layered Architecture. To avoid misunderstandings, let me note that I will present the Layered Architecture as I was taught/learned, which might be different than the one you know or some sources present. Enjoy!

What Is Layered Architecture?

A Layered Architecture, as I understand it, is the organization of the project structure into four main categories: presentation, application, domain, and infrastructure. Each of the layers contains objects related to the particular concern it represents.

  • The presentation layer contains all of the classes responsible for presenting the UI to the end-user or sending the response back to the client (in case we’re operating deep in the back-end).
  • The application layer contains all the logic that is required by the application to meet its functional requirements and, at the same time, is not a part of the domain rules. In most systems that I've worked with, the application layer consisted of services orchestrating the domain objects to fulfill a use case scenario.
  • The domain layer represents the underlying domain, mostly consisting of domain entities and, in some cases, services. Business rules, like invariants and algorithms, should all stay in this layer.
  • The infrastructure layer (also known as the persistence layer) contains all the classes responsible for doing the technical stuff, like persisting the data in the database, like DAOs, repositories, or whatever else you’re using.

There are two important rules for a classical Layered Architecture to be correctly implemented:

  1. All the dependencies go in one direction, from presentation to infrastructure. (Well, handling persistence and domain are a bit tricky because the infrastructure layer often saves domain objects directly, so it actually knows about the classes in the domain)
  2. No logic related to one layer’s concern should be placed in another layer. For instance, no domain logic or database queries should be done in the UI.

Image title

The Essence of Layered Architecture

Architecture is kind of an overloaded term, so we should probably dig deeper into what the term really means in the context of layers. The main idea behind Layered Architecture is a separation of concerns – as we said already, we want to avoid mixing domain or database code with the UI stuff, etc. The actual idea of separating a project into layers suggests that this separation of concerns should be achieved by source code organization. This means that apart from some guidance to what concerns we should separate, the Layered Architecture tells us nothing else about the design and implementation of the project. This implies that we should complement it with some other architectural processes, such as some upfront design, daily design sessions, or even full-blown Domain-Driven Design. Whichever option we choose doesn’t matter, at least for the sake of layering, but we need to remember: Layered Architecture gives us nothing apart from a guideline on how to organize the source code.

Implementing Layered Architecture

Equipped with the knowledge of the layers to create, the relationships between them and the essence of the architecture, we are ready to implement it. As most of you probably expect, we will slice the system into layers by creating a separate package for each of them. When it comes to applying the dependency and separation rules, things are not so obvious. One could try putting each layer in a separate Maven module, but then capturing the weird relationship between domain and persistence would not be easy. I usually stick with packages and use common sense along with code reviews to make sure that none of the rules are broken.

Layering Spring Pet Clinic

Since I didn’t want to force you to learn a new project just to grasp a simple idea, I decided to use a project that all Java developers should be familiar with – Spring Pet Clinic. At the time of writing this post, the project uses some weird packaging, that is probably supposed to be more domain-oriented. Let’s see how the two ways of code organization stack against each other:

Image title

I’ll leave the interpretation to you. One thing that I did not expect, which is now clear, is that there were no application services in the project – almost everything is done in the controllers! I haven’t seen it until I actually moved the classes to their best-fit layer packages.

Benefits of a Layered Architecture

Although some of you might still not believe it, Layered Architecture has some benefits, including:

  • Simplicity – the concept is very easy to learn and visible in the project at first grasp.
  • Consistent across different projects – the layers and so the overall code organization is pretty much the same in every layered project.
  • Guaranteed separation of concerns – just the concerns that have a layer and to the point that you stick to the rules of Layered Architecture, but it’s very easy with the code organization it implies.
  • Browsability from a technical perspective – when you want to change something in some/all objects of a given kind, they’re very easy to find and they’re kept all together.

Drawbacks of a Layered Architecture

And, of course, Layered Architecture is not perfect. Some of its cons include:

  • No built-in scalability – when the project grows too much, you need to find a key to organizing it further by yourself. The principles of Layered Architecture won’t help you.
  • Hidden use cases – you can’t really say what a project is doing by simply looking at the code organization. You need to at least read the class names and, unfortunately, sometimes even the implementation.
  • Low cohesion – classes that contribute to common scenarios and business concepts are far from each other because the project is organized around separating technical concerns.
  • No dependency inversion – in a classical Layered Architecture, the dependencies are direct and, conceptually, changes from a low-level infrastructure layer can propagate to more important higher layers.

When to Apply Layered Architecture

At first, I wanted to write some cases when I use Layered Architecture myself, but I think we could use a more methodical approach based on its pros and cons:

  • Simplicity: That’s obviously important for everyone. The non-existent learning curve makes it especially viable for low-experience teams and the ease of applying for projects with no budget to invest in a more advanced architecture.
  • Consistency: Multiple small projects handled by the same group of people, such as an internal architecture for microservices.
  • Separation of concerns: Low-experience teams.
  • Technical browsability: To some extent, it helps everyone. It depends on what you’re trying to find at a given moment.
  • No built-in scalability: Projects that are supposed to stay small, such as microservices, or larger projects that can be easily factored into smaller pieces.
  • Hidden use cases and low cohesion: Projects with no or few complex business scenarios, such as CRUD operations or simple REST services.
  • No dependency inversion: Projects with few dependencies on the infrastructure, in which there are no serious low-level changes to actually propagate higher.

Summary

As you can see, a Layered Architecture has its bright and dark sides. To me, its simplicity and consistency make it a good fit for microservices without too much serious business logic. One could question if such microservices should exist in the first place, but the realities of factoring big monoliths often make them a lesser evil. The most important lesson that you should take away from this article is: Layered Architecture is about organizing code for a good separation of concerns and nothing else, really.

Architecture Database microservice application Dependency Infrastructure Design Object (computer science) End user Web Protocols

Published at DZone with permission of Grzegorz Ziemoński, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • How To Use Terraform to Provision an AWS EC2 Instance
  • How to Quickly Build an Audio Editor With UI
  • Building a Scalable Search Architecture
  • The 12 Biggest Android App Development Trends in 2023

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: