Clean architecture is an architectural style for building IT applications. At the heart of clean architecture and similar styles, such as hexagonal architecture, is the ability to test and develop the technical application independently of the rest of the infrastructure. In clean architecture, the business rules therefore form the actual core of the application and thus define its value. Especially in complex software projects, further development is never complete. Clean architecture therefore prevents individual software solutions from influencing the overall process and thus burdening and hindering business processes. Likewise, infrastructure components can be defined late or exchanged or replaced, which is another advantage of clean architecture over traditional three-layer architectures.

Clean architecture vs. three-layer architecture

Many systems still use a three-layer architecture. The logical layers of this style are as follows:

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

In this structure, it is essential that the components of one layer are only dependent on those of the layer directly below it. This makes it possible to replace a higher layer without affecting any of the layers below it. In terms of the process, the presentation layer (user interface layer) interprets the user’s input and calls the corresponding 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 that affect persistent data must first be made in the database and then implemented from the bottom up through the layers. This configuration makes testing the actual application time-consuming and slow and greatly complicates further development. For this reason, such a three-layer architecture in its pure form is rarely found today. Instead, such systems are sometimes reworked through refactoring so that the business logic no longer has a direct dependency on the database.

Building a ‘clean architecture’

In a ‘clean architecture’, the business logic is not decoupled from the database by a trick, but instead offers a high-level interface that is implemented by a persistence mechanism. This shifts the dependency from the data access layer to the business logic layer at the architectural level. As a result, the business logic becomes independent of technical details. This even allows the business logic to be implemented and tested before a database is available.

This also makes it possible to decide which database technology is most suitable for the application’s requirements only after extensive testing has been carried out. As a result, both data access and GUI components are dependent on the business logic, while the latter remains completely independent of both. This means that only after extensive testing can a decision be made as to which database technology is best suited to 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, the business logic should be developed independently of the GUI, just as it is developed independently of the database.

Further layers are superimposed on the core of the business rules, which transport the business logic further outwards. The inner circles are guidelines, the outer ones are mechanisms. The special feature here 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 exchanged while the core process remains intact. Put simply, the further inside, the closer to the technical core, and the further outside, the closer to technical details.

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

 

Properties of systems with a ‘clean architecture’

With the business rules, i.e. the business logic at the core of the architecture, systems are ultimately created that fulfill the following conditions:

• Independence from frameworks. The architecture does not depend on a feature-laden software library. This makes it possible to use frameworks as tools instead of forcing the business rules into an existing system framework.
• Testability. Because they are decoupled from the system, the business rules can be tested at any time without a user interface, database, server, or other external elements.
• Independence from user interfaces. The business rules remain valid even if the interface changes: they can be mapped via a command line just as easily as via a graphical user interface.
• Independence from databases. The type of storage and management of the rules is not dependent on a specific architecture.
• Independence from external influences. The business rules have no connection to the outside world.

Use of ‘clean architecture’

The effort required 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, this includes the implementation of warehouse management software, i.e. warehouse management systems or material flow control, in large distribution centers. Due to the maximum flexibility and independence of all components and processes, ‘clean architecture’ is particularly suitable for some markets. The principle can bring enormous advantages, especially in application areas characterized by long project durations, high degrees of complexity, and volatile market situations. In such competitive environments, technical or functional changes are constantly required that do not affect the entire system, which is why it is a great advantage to be able to avoid interdependencies and use business rules as a central element. Clean architecture is often used in combination with domain-driven design or context-aware front-end 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 contrasts with the classic three-layer model in that the business logic and thus the business rules form the core of the structure. The business logic is completely decoupled and therefore independent of frameworks, databases, and user interfaces. This results in high testability in terms of speed and simplicity, as the components of other layers do not need to be touched or adapted. ‘Clean Architecture’ is particularly suitable for complex applications that run over a long period of time and, depending on frequently changing requirements, need to be maintained, adapted, and modified accordingly.

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