Demystifying Clean Architecture: Fundamentals and Benefits
Tags: webdev, cleancode, cleancoding, cleanarchitecture
Published: 2024-05-02 08:30:59

Imagine building a house with an inconsistent plan, where walls, roof, and foundations blend into a cheerful chaos... Well, that's exactly what the world of development can look like! Let's not kid ourselves; it happens (far too) often. We've probably all faced the spaghetti plate, a code where everything is mixed up and hard to maintain. Clean Architecture will be the master builder accompanying the construction of the house, bringing a framework that brings order to the increasing complexity of modern applications.

## What is Clean Architecture?
Clean Architecture is not just a buzzword. Resulting from the work of Robert C. Martin (a publication in 2012 followed by a book in 2017 still available), it is an increasingly essential concept in modern development that offers a structured approach to designing robust, more easily maintainable, and scalable applications.
**Let's first define the basics.**

### Definition
Clean Architecture aims to **clearly separate concerns**, with business aspects on one side and technical aspects on the other. It also aims to maintain **essential control over dependencies**, avoiding being tightly bound or coupled to them.

These are the two fundamental principles:

**1- Separation of Concerns**
With Clean Architecture, imagine each element of your application having a clear and distinct role. **Business logic doesn't mix with technical details.** The application is divided into layers, each with its responsibility.

**2- Independence of Frameworks and Tools**
Here, flexibility is key. **Your application must be agile and able to adapt to changes without compromising its stability.** A significant security flaw in one dependency? GDPR constraint on another? No matter, adapting the code, replacing it with another dependency, should be painless.

### The Layers of Clean Architecture
In the definition part, we discussed decomposing into several distinct layers, each with a specific responsibility and role, following the principle of isolation. **Let's dive into the details**.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xpunh8xsdzps11zt20m0.png)

**The Entities Layer**
Entities form the heart of domain modeling, business. **They are the building blocks of your application, guardians of business logic**, without worrying about technical details, data persistence, etc.

**The Use Cases Layer**
Use cases are like conductors of your application. **They direct business logic and ensure that everything runs smoothly** with coordination between different parts of the application. They clearly describe business logic scenarios. I like to emphasize that the Product Owner's perspective can be interesting in this layer!

**The User Interfaces Layer (Interface Adapters)**
In this layer, we deal with interactions with the outside world. **User interfaces and adapters handle inputs and outputs**, like a gateway between the application and external dependencies.

**The Infrastructure Layer**
Finally, the infrastructure layer is the lair of technology. **It is responsible for interacting with databases, frameworks, and everything related to technical aspects.**

Each layer is isolated, independent. To make them communicate with each other, we'll use what's called dependency injection.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/41acdil56rfg1w8r5nw9.png)

## Why Choose Clean Architecture?
Now that we've seen the fundamentals and understand the basics, let's look at the **concrete advantages** of Clean Architecture principles.

**Better Maintainability & Scalability**
Our master builder has fulfilled its mission, the house is well-designed, and each room adapts to a single need. If I want to add a room or change a window, it's immediately simpler! **Clean Architecture brings this flexibility, allowing the application to adapt and grow without difficulty.** Unlike spaghetti code, where pulling on one side causes crashes elsewhere.

**Better Testability**
It's quite logical that with the principle of isolation, separation of concerns, where each layer has its responsibility, **the code structure facilitates the implementation of unit tests.** Simple elements lead to simple tests, simple tests mean more robust code.

**Technical Independence**
Still in our house, think of being able to change furniture without affecting the basic structure. This is exactly one of the fundamental principles of Clean Architecture, **the independence of the technical layer.** If changing the table requires changing the tiles, two walls, and three windows, it's immediately another project!

**Clearer Understanding of the Code Base**
By following the principles of separation of concerns at the code structure level, **developers find a clear path within and between each layer**, facilitating the understanding of the different parts of the application.

**Disadvantages?**
Of course, as often in the world of development, everything is not black or white. If we have advantages, we have disadvantages too: More complexity in development, a slightly steeper learning curve, it can be interesting to climb a few steps by following training. We can also add a larger source code size, or what can be considered as overdevelopment, and complexity during the initial configuration.

## To Conclude
Clean Architecture is not just a development method; it is a philosophy that changes the way we design our applications. **By adopting its principles, we ensure developing robust, scalable, and easier to maintain applications.** And inevitably, it's also an improvement in the developer experience, which we'll address in a separate article.

But it's not a magic solution either! It's a development architecture, like others, and like others that will come tomorrow. **It's up to you to determine** if Clean Architecture is a good choice for your project, your context. In one of my experiences, we developed a POC, with the aim of validating a market and Web 3 technical specifications. We were moving forward without real functional specifications; each day brought, removed, modified a feature: It would have been too expensive to ensure having a clean structure for code that we had already planned to "discard."

But anyway, with the rise of generative AIs or Low Code / No Code applications (and both at the same time tomorrow?), **the market share of applications developed with a tool will continue to grow** and take its place, that's my conviction. Any application that doesn't fall into this category will inevitably be more complex, will require addressing challenges that Low Code / No Code or AI cannot solve. So, it will necessarily require a **solid, robust, scalable, maintainable structure**, everything that Clean Architecture offers today, and why not a new method or new principles tomorrow!

This article is an introduction to Clean Architecture and is part of a dedicated series on this topic. Stay tuned for more!

Want to learn how implement it with typescript and express? See my udemy course! In [french](https://www.udemy.com/course/clean-architecture-avec-typescript-et-express/?referralCode=8C9C5BF69F624247D63A) or [english](https://www.udemy.com/course/clean-architecture-with-typescript-and-nodejs-express/?referralCode=A0683A3DE7EDE1BD15A0) 😉

Articles on Clean Architecture:

- [Clean Architecture : Infrastructure vs Core](https://dev.to/nlapointe/clean-architecture-infrastructure-vs-core-492k)
- [Clean Architecture: Business rules first!](https://dev.to/nlapointe/clean-architecture-business-rules-first-4dlo)
- [Introduction to the principles of clean architecture in a NodeJs API (Express)](https://dev.to/nlapointe/introduction-to-the-principles-of-clean-architecture-in-a-nodejs-api-express-13e9)