What is Clean Architecture?

In this quick introduction I will show you the key concepts and benefits around the clean architecture that helped me understand the idea behind it.

So, let's go straight to the point:

Clean architecture is a software design created by Robert C. Martin and published in Clean Coder Blog that focuses on separating concerns and decoupling dependencies within a system. Also, provides a set of guidelines that divides your project into layers to build a maintainable, testable and scalable systems.

The clean architecture benefits:

We want switch or test another framework: we only have to make a change in one place without cause a ripple effect in others.
All business logic as use case: no boilerplate code and easy to find.
Independent of UI: We should able to change the presentation layer easily without affect the rest of the system.
Independent of Database: The capacity to change the database without affecting the rest of the system and how the users get the data.
Independent of any external agency: The business rules are an atomic component (entities). They don't know anything about the external world.
Easy to test: We just need to create some mocks and supply the correct assembly to the dependency injection in your tests.
Keep away from the chaos: Presentation, business logic/rules and data access should never to be connected so as to be difficult to separate.

The clean architecture is explained with the following diagram:

Inner circles

The inner circles contains the business logic and rules without dependencies on any third-party library which allows us to use a framework as a tool and not adapt the system of a specific technology.

Entities: Encapsulate all business rules without external dependencies which could be used by different applications.

Use Cases: Contains the business logic for specific usage scenario which orchestrate the flow of data to and from the entities.

Outer circles

The outer circles usually contains frameworks, databases and 3rd party tools. Change the tool or framework in any outer circle doesn’t affect the inner circles.

Interface Adapters: Is a set of components that convert the data from external sources like API request or other systems to the most convenient format for the use cases.

Frameworks and drivers: Frameworks, tools, libraries... for example; The implementation of web server, databases and logger should be in this layer.

The Dependency Rule

When you adopted the clean architecture you must follow "The Dependency Rule":

This rule says that source code dependencies can only point inwards. Nothing in an inner circle can know anything at all about something in an outer circle. In particular, the name of something declared in an outer circle must not be mentioned by the code in the an inner circle. That includes, functions, classes. variables, or any other named software entity.

The arrows represents the dependence flow, indicating that one outer circle can depend on an inner circle but that an inner circle can not rely on an outer circle which ensures that components or classes are independent.

From now on, we can continue reading the rest of the "Clean Architecture Series"

See you then.

What is Clean Architecture?

Clean Architecture with Typescript

Defining the application flow of the Clean Architecture Project

More from this blog

The frontend infrastructure we keep rebuilding

Building a backend without giving your architecture to a framework

The 14 rules of CANDO-TEST

CANDO-TEST: A clearer architecture for UI test automation

Debugging a Deno program with VSCode

Inner circles

Outer circles

The Dependency Rule

Command Palette

Clean Architecture with Typescript

Defining the application flow of the Clean Architecture Project

More from this blog

Inner circles

Outer circles

The Dependency Rule