Clean Architecture

Over time, software architecture has been defined in many different ways. Formal definitions have stated that it is the fundamental composition of a system, or the way top level components are put together. Others have said it is the decisions that they wish they had made correctly early in a project. But in the end, architecture is all the important things, and they vary from system to system.

Layercake of frozen music

Software architecture is important because it helps in the constant evolution of a system without making it too expensive or prohibitive. Clean architecture was first intro­duced by Robert C. Martin with a blogpost in 2012 and aims to do just that. So, what is clean architecture, whenand where should it be used?

What is clean architecture?

Clean architecture is a software design philosophy which aims to maximise the separation of concerns in a system and promotes the use of clean code and SOLID principles. The separation of concerns is achieved by splitting the software into layers. A system built following clean architecture:

  • is independent of frameworks as those frameworks are hidden behind interfaces and can be easily switched.

  • is testable since the business rules are not dependent on any other layer.

  • is independent of any UI or database as those can be switched out easily like the frameworks.

Grafische Darstellung. Rechts ein Kreisdiagramm. Im lilafarbenem Zentrum ist das Wort Entities. Darum bildet sich ein roter Ring mit dem Wort Use Cases. Dieser wird eingeschlossen von einem orangenem Ring in dem Controllers, Presenters und Gateways steht. Der äußerste Ring ist blau gefärbt und trägt die Begriffe Devices, Web, UI, Ext. Interfaces und DB in sich. Links neben dem Kreisdiagramm findet sich die Legende. Lila steht für Enterprise Business Rules. Rot für Application Business Rules, orange für Interface Adapters und blau für Frameworks & Drivers. Darunter befindet sich noch eine Mindmap. Ganz oben links ist ein oranges Feld in dem Presenter steht. Dieses deutet mit einem Pfeil auf das Feld rechts daneben in dem "Use Case Output Port" steht. Dieses Feld führt zu dem darunter welches "Use Case Integrator" enthält. Unter dem Presenterfeld ist die Beschriftung "Flow of Control". Darunter ist ein Feld mit "Controller" zu sehen. Das Controllerfeld führt rechts mit einem Pfeil zu einem Feld mit "Use Case Input Port".

Layers of clean architecture

The four layers shown above are of course not the only layers that could exist, more layers can be added if needed depending on the problem. The only thing that should be kept in mind while doing so is the dependency rule. According to the rule, dependencies can only point inwards. Inner layers should never depend on the outer layers.

Entities is the innermost layer, they encapsulate business rules, or things that will always be true or static for an appli­ cation. Entities can just be objects with methods or just simple data structures and functions. This layer is the least likely to change in the lifetime of an application and should not be affected by changes in other layers.

Use Cases is the next layer up, they implement the use cases of the system by interacting with entities and exchanging data between them to achieve the corre­ sponding goals. Essentially, they dictate what interactions can be achieved with the system.

Curious? Read more now.

Here you can download the complete UXMA Trend Report 2022 free of charge and benefit from other exciting articles!

Insights

Ready to start something big together?