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.

Graphical representation. A pie chart on the right. In the purple center is the word Entities. Around it is a red ring with the word Use Cases. This is enclosed by an orange ring containing the words Controllers, Presenters and Gateways. The outermost ring is colored blue and contains the terms Devices, Web, UI, Ext. interfaces and DB. To the left of the pie chart is the legend. Purple stands for Enterprise Business Rules. Red stands for Application Business Rules, orange for Interface Adapters and blue for Frameworks & Drivers. Below this is a mind map. At the top left is an orange field containing Presenter. This points with an arrow to the field to the right of it, which says "Use Case Output Port". This field leads to the one below it which contains "Use Case Integrator". Below the presenter field is the label "Flow of Control". Below this is a field with "Controller". The controller field leads to the right with an arrow to a field with "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?