Clean Architecture Part One: What is Clean Architecture?

Cagri Tezel
inventiv
Published in
4 min readJan 6, 2023

--

On the 13th of August, 2012, Robert C. Martin (a.k.a. Uncle Bob) published in his blog “Clean Coder”, after in his book “Clean Architecture: A Craftsman’s Guide to Software Structure and Design”, a new architectural philosophy: Clean Architecture. Over the years, Clean Architecture has become popular and widely used ever since.

But, what is Clean Architecture? What it suggests us to do? In this publication, Part One of The Clean Architecture series, we will talk about Clean Architecture and its foundations, suggestions, and where to use it.

In Part 2, the theory will meet with practice.

So, let’s dive on in.

What is Clean Architecture?

https://blog.cleancoder.com/uncle-bob/images/2012-08-13-the-clean-architecture/CleanArchitecture.jpg

This is the original image that is used in the blog and in the book. The very first thing you see is layers with arrows toward inward, some words on these layers and diagrams. It seems a little bit confusing, so I will talk about Clean Architecture on image below since I have experienced this one in my professional life. I commonly used this architecture in REST APIs. Therefore, layer names and their materials can be a little different for you.

https://i0.wp.com/jasontaylor.dev/wp-content/uploads/2020/01/Figure-01-2.png?w=531&ssl=1

Clean Architecture is a design philosophy that encapsulates the business logic and keeps it separated from other concerns of a project, by just the structure of the project.

There are four layers present in this figure. The outer layers are mechanisms, the instruments that interact with the outside world. The inner layers are business policies. No inner layers can know anything about outer layers. A layer is used by the outer layer, and uses the inner one.

Let’s talk about the layers.

Presentation (API, GUI, etc.) Layer

This layer, as its name, interaction layer of a project with the outside world.

This layer can consist of,

  • API Endpoints
  • API Models
  • Filters
  • Controllers
  • Views
  • Interfaces, etc.

It is a low-level layer and can only interact with the application layer.

Infrastructure Layer

The Infrastructure layer contains tools such as databases, frameworks, and implementations of API clients, message brokers, and communications. All the external details of the system reside in this layer.

As the project grows, a persistence (database) layer can be extracted in order to manage the layer more efficiently.

Application Layer (Use Cases)

The Application layer consists of application-specific business rules, use cases, and includes all of the use case scenarios of the application. These use cases control the flow of data interchange toward the Domain layer.

Changes in other layers don’t affect the application layer, but changes in the operation of the application necessitate changes on use cases and this layer.

Domain Layer (Core)

The Domain layer encapsulates critical enterprise business rules of any system, which are entities.

Entities are the most general and high-level rules of your application, and they must be abstracted from outer layers. Entities probably will not change if there is an external change (such as changing DB, changing from Vue to React, etc.).

Besides entities, this layer can consist of,

  • Domain events
  • Domain Services
  • Domain Exceptions
  • Repository interfaces
  • Message Broker interfaces
  • Specifications, etc.

The Benefits of the Clean Architecture

Independence!

The Clean Architecture is what a rebellious developer wants to have. Independence from which web framework to use, which language to use, which database to use ,and so on. Every part of this architecture is independent, like plugins. A Change in the infrastructure layer, like a change in the database system, will not affect a change in the domain layer.

And it is highly testable since it is modelized. Unit testing will be much more easy to apply, since every layer communicates with interfaces.

Conclusion

Do we really need to use Clean Architecture?

Of course not. If you have a very small project with only 3–4 endpoints and it is unlikely to change, do whatever you want. In that case, trying to use Clean Architecture will be a waste of time and source for you.

But many of us have seen over the years, something that starts as a small project can be gargantuan in a year or two. On enterprise level projects, Clean architecture will need much more effort, time, and resource at first. But after production, this architecture makes your project more manageable.

Thanks zeynep yildiz for her collaboration.

References

1- https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

2- Clean Architecture: A Craftsman’s Guide to Software Structure and Design, Robert C. Martin, 2017

3- https://jasontaylor.dev/clean-architecture-getting-started/

--

--