Clean architecture’ is an IT application implementation style. At the heart of clean architecture and similar styles such as hexagonal architecture is the ability to test and develop the business application independently of the rest of the infrastructure. Therefore, in clean architecture, the business rules form the actual core of the application and thus define its value. Especially in complex software projects, further development is never complete. Clean architecture has the effect of preventing individual software solutions from influencing the overall process and thus burdening and hindering business processes. Likewise, components of the infrastructure can be defined at a later stage or also exchanged or replaced, which represents a further advantage of the clean architecture in comparison to traditional three-layer architectures.

Clean architecture vs. three-tier architecture

A three-tier architecture is still used in many systems. The logical layers of this style are as follows:

• Presentation layer ( accounts for the presentation to the user)
• Business logic layer (contains the business rules)
• Data access layer (processes the communication with the database)

In this design, it is fundamental that the components of a layer may depend exclusively on those of a layer directly below it. This makes it possible to replace a higher layer without affecting any of the layers below it in any way. In terms of flow, the presentation layer (User Interface Layer) interprets the user’s input and calls the appropriate functionality in the business logic layer (Domain Layer), which in turn calls the data access layer to evaluate or modify data from a database.

In such an architecture, the entire system depends on the data access layer and thus on the database itself. As a result, changes to the application, as soon as they affect persistent data, must first start in the database and then be made from the bottom up through the layers. This constellation makes testing of the actual application laborious and slow, and also hampers further development enormously. For this reason, such a three-layer architecture hardly ever occurs in current IT systems in its pure form. Rather, such systems are sometimes rebuilt through refactoring so that the business logic no longer has a direct dependency on the database.

Structure of a clean architecture

In a clean architecture, the business logic is not decoupled from the database by some artificial means, instead, it provides a high-level interface implemented by a persistence mechanism. This shifts the dependency from the data access layer to the business logic layer at the architecture level. This leads to the business logic becoming independent of technical details. As a result, it is even possible to implement and test the business logic before even having a database.

This also makes it possible to decide which database technology is most suitable for the requirements of the application after extensive testing has taken place. In the course of this, both data access and GUI components are dependent on the business logic, while the latter remains completely independent of both. Consequently, extensive testing is possible before reaching a decision on which database technology is most suitable for the requirements of the application. As a result, both data access and GUI components are dependent on the business logic, while the latter remains completely independent of both. For this reason, business logic should be developed independently of the GUI just as it is developed independently of the database.

On top of the core of business rules are additional layers that further transport the business logic to the outside. The inner circles are policies, the outer ones are mechanisms. The unique characteristic is that dependencies in the source code may only refer from one outer circle to the next inner circle, which Robert C. Martin also calls the dependency rule in his article. This allows the outer layers to be easily adapted and replaced while the core process remains intact. Put simply, the further in, the closer to the business core, and the further out, the closer to technical details.

The structure of a clean architecture is illustrated in the following graphic:

Properties of systems with a ‘clean architecture’

Finally, with the business rules, that is, the business logic at the core of the architecture, systems are created that meet the following conditions:

• Framework Independence. The architecture does not depend on a rich feature-loaded software library. This allows frameworks to be used as tools rather than forcing business rules into an existing system corset
• Testability. By decoupling the business rules from the system, they can be tested at any time without a user interface, database, server, or other external elements
• Independence on user interfaces. The business rules persist even if the interface changes: They can be mapped via a command line in the same way as via a graphical user interface
• Database independence. The way rules are stored and managed is not dependent on any particular architecture
• Independence on external influences. Business rules have no connection to the outside world

Use of clean architecture

The effort to implement a ‘clean architecture’ is particularly worthwhile for complex applications that are likely to require maintenance over a long period of time because they support relevant business processes. In intralogistics, for example, this includes the implementation of a warehouse management system or the material flow control in a large distribution center. Due to the maximum flexibility and independence of all components and processes, a ‘clean architecture’ is therefore particularly suitable for complex projects over a longer period in dynamic markets. In such a competitive environment, changes in business or technology are constantly occurring that do not affect the entire system, which is why it is of great advantage to be able to avoid interconnections and to use business rules as a central element. Clean architecture is often used in combination with domain-driven Design or context-aware frontend architecture, especially in agile environments with self-contained systems and micro-services.

Summary

‘Clean architecture’ is an architectural style for IT systems and applications that opposes the classic three-tier model in that the business logic and thus the business rules form the core of the structure. The business logic is completely decoupled and thus independent of frameworks, databases and user interfaces. This leads to high testability regarding speed and simplicity since the components of other layers do not have to be touched and/or adapted for it. Clean architecture is particularly useful for complex applications that run over a long period of time and need to be maintained, adapted and changed frequently, depending on the volatile market conditions.

Back to home page.
Go to category overview.
To the article ‘Context Aware Frontend Architecture’

Also available in Deutsch (German)