Clean Architecture: The Benefits of Building Clean Architecture for Enterprises

The essence of Clean Architecture is selecting an architecture and coding methods for systems that reduce the costs of their creation, operation, development, and modernization throughout their entire lifecycle. This minimizes the total cost of ownership of a system while simultaneously maximizing the productivity of the development team. Robert C. Martin, the creator of the Clean Architecture concept, once wrote that “any organization that designs a system will inevitably produce a design whose structure is a copy of the organization’s communication structure”[i]. There is a lot of truth in this statement – diligence in design and coding is closely linked to the organizational culture of the entire company. Correct choices at the design stage and high-quality work by developers ensure that the code is easy to understand, develop, and maintain, and that the deployment itself proceeds quickly and smoothly.    

What exactly is Clean Architecture?

At the foundation of Clean Architecture lies the assumption that formulated business requirements should have minimal connection to specific technology and implementation details. Therefore, all layers forming the project structure should have clearly defined tasks and responsibilities, while being easily isolatable from the solution as a whole. Going further, Robert C. Martin proposed designing systems so that as much code as possible can be shared across multiple environments. In his original proposal, four layers could be distinguished:

1. application,
2. presentation
3. domain/business logic

The two main layers—presentation and domain logic—are independent of the technology used to create the application and can be shared, while the application and data layers are closely tied to the runtime environment and the tools used. Thus, when combined, we have a situation where one can write the domain logic once and then share it across mobile applications on iOS and Android, as well as in web and desktop systems. A common feature of layers defined in this way is their independence from frameworks, which are treated solely as tools. Furthermore, they are easily testable because business logic is separated from hard-to-test elements such as databases or user interfaces. In the Clean Code Architecture concept, the application layer is most strongly connected to specific technology and tools. Its task is to provide the graphical interface and data visualization. The application layer decides how to display the provided data and how to react to tasks arriving from the presentation layer. On one hand, it must contain display rules, and on the other, it must be able to inform the presentation layer about any user actions in response to appearing data and events. Built into the presentation layer are mechanisms controlling the entire application, individual screens, reactions to user actions, or data handling. Decisions on how to handle specific tasks or which part of the application to show the user and in what order are also made in this layer. Presentation layer interfaces communicate with views, but this is a one-way communication—to the views. Properly designing the presentation layer requires understanding how real business processes work. Solutions in the Business Process Discovery (BPD) class are perfect for this. The presentation layer can be built using one of the available design patterns such as: Model View Controller (MVC)[ii], Model View Intent (MVI)[iii], Model View ViewModel (MVVM), or Model View Presenter (MVP). The choice is a secondary matter, and developers decide on the pattern themselves.

Clean architecture – key concepts

Clean architecture can be visualized as concentric circles corresponding to individual architectural layers, with the highest-level layer in the center. Thus, at the center, we have domain logic and entities, i.e., business objects. It is worth remembering that domain logic, or in a slightly narrower sense – business logic[iv], concerns rules functioning in a given area of human activity. Such invariants function regardless of whether any software using this logic has been created. An example could be calculating income tax or the process of tracking a shipment to a customer. All significant business processes and workflows must also be reflected in this layer. The components of the domain logic layer include:

1. UseCase – a component whose task is to map true and real business requirements and provide the presentation layer with access to data operations – e.g., retrieving or modifying values through calculations. Interestingly, UseCase is the only way to exchange data between the presentation layer and the domain logic layer.
2. Model – a collection of data organized according to selected rules, which are used by business logic. Models in this layer can differ significantly from models in the data layer, e.g., by combining several models into one, depending on needs.
3. Logic – a place in the structure used to store isolated classes describing complex cases of domain logic that are used less frequently. This avoids overly complex UseCases.
4. DataSource – these decide where data is retrieved and saved and have access to all data sources provided by the data layer. They are therefore the only connection between the domain logic and data layers. The task of the DataSource is to prepare data for processing in the UseCase.
5. Mappers – ensure the consistency and completeness of data provided by the data layer so that the domain logic can function flawlessly. Mappers often integrate several objects from different sources in the data layer to create one object that contains all the data necessary from the perspective of domain logic.

The task of the data layer is to provide access to all data sources and models mapping that data. Access to methods contained in this layer is possible only through its own interfaces. It is worth noting that the data layer is very strongly tied to the platform and tools used by the clean architecture of IT systems. Among the most important constructs in this layer, one can find:

1. Data Transfer Object (DTO), i.e., a model for bidirectional data transfer. They are used only in this layer, and their services are used by mappers or business models, depending on the direction of data transfer.
2. Data – these are places for retrieving and saving data used in other modules of the system. Appropriate interfaces allow for easy and fast replacement of data sources – it is enough to provide appropriate objects implementing these interfaces to replace data arriving via Bluetooth with a stream of data from the internet, a GPS system, or a camera. Such replacement of data sources is most often used when handling different types of servers or using test data.

In literature on Clean Architecture, one also encounters the concept of an interface adapter, i.e., a connection between the UseCase and system interfaces and data adaptation for both adjacent layers.

What are the advantages of the Clean Architecture approach?

The most important and significant advantage of using Clean Architecture is the ease of maintaining and developing the project code. Locating and fixing any bugs is very simple with this approach. Even at the level of naming variables, Robert C. Martin recommended taking as much care as naming one’s first child. A long descriptive name is better than a short and enigmatic one, and even better than a long descriptive comment. This makes change management simpler. The Clean Architecture approach, thanks to small classes with separated responsibilities, allows for quick and easy code modification to meet new requirements. Adding new functionalities is similar, without fear of consequences in other parts of the project. The aforementioned large number of small classes and interfaces allows for better and more careful testing of every piece of code, which reduces technical debt[v], which usually arises in situations of increased time pressure and business requirements. All this translates into lower costs of project management and subsequent operation and development of the application.

What are the disadvantages of the Clean Architecture approach?

Of course, bad code can always be cleaned and improved, but it is usually very expensive and, worst of all, time-consuming, and time is the only resource that cannot be recreated. When applying Clean Architecture rules, one must remember that they require about 10% additional effort for planning and writing code. The disadvantages of this approach also include a high entry threshold – to use clean IT system architecture, advanced knowledge is simply required. For many practitioners, a large number of small classes and interfaces also means many files to manage, which can be a separate challenge in larger projects. A completely separate issue is the area of application of Clean Architecture – it will not be the right approach for every type of application; sometimes RAD (Rapid Application Development) might prove better, especially when quickly creating prototypes or for applications with a known lifecycle and a clear, well-defined goal. The lack of far-reaching universality can also be counted as a weakness of this concept.    

In which projects will Clean Architecture work best?

Clean Architecture is a heavy-caliber tool. Therefore, it is worth deploying it for projects of an appropriate scale where high performance and diverse functionality are required. For tasks that are too small, the time investment for additional work is simply too high. However, one must be careful – sometimes something small can hatch into a quite large and substantial application. Early application of Clean Architecture allows for avoiding the creation of significant technical debt, which can hinder the development of a promising project for a long time. It is therefore worth taking to heart the remarks of Robert C. Martin, who stated that clean code always looks like it was written by someone who cares about it.[i] Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship, Financial Times Prentice Hall; 1st Edition, (August 14, 2008). [ii] https://cycle.js.org/model-view-intent.html#model-view-intent-what-mvc-is-really-about [iii] https://cycle.js.org/model-view-intent.html#model-view-intent [iv] http://tymoteuszkestowicz.com/2019/01/logika-biznesowa-to-nie-jest-logika-aplikacji/ [v] https://goodpoint.blog/dlug-technologiczny-czym-nim-zarzadzac/