Straight to the point: Clean architecture
As part of my Individual Development Program (IDP), I have been dedicated to studying the theory of knowledge I have acquired throughout my career as a Swift developer. This article details my studies based on the clean architecture book.
First Impressions
Reading this book provided a fundamental understanding of the concept of architecture and how to organize its parts to build a cohesive whole. Although the book covers other topics related to architecture in a more general sense, I still highly recommend it as an essential part of professional development.
A widely discussed and referenced concept in the book is that of layers. Throughout the reading, I came to understand that this term actually encompasses two other concepts: context and dependency. Context refers to a group of objects that have a common purpose, whether it’s defining the application’s domain or integrating the network interface into the project. Dependency, on the other hand, establishes the rules that define which other contexts can be considered dependencies for the given context.
Through this book, I understood why the domain (Domain) is always a central element when it comes to architecture. It defines the essential foundation of the project from which all other implementations derive.
Therefore, reading this book is much more about technical development and understanding what architecture is than simply implementing it following a specific tutorial. That’s why there isn’t ready-made code available on the internet when it comes to clean architecture.
Clean Architecture
Clean architecture emphasizes the importance of project independence from the system, considering system units such as the user interface, printer, USB drives, among others.
The goal is to create a highly organized structure, minimizing dependencies between system units and facilitating project adaptability over time. This approach avoids unwanted influences and promotes a solid and adaptable architecture. Thus, clean architecture aims to prevent issues caused by weak and poorly planned architectures.
A solid architecture enables new developers to have an accelerated learning curve, finding support through documentation and collaboration with peers. Conversely, an architecture that mixes various design patterns due to transient influences from developers who do not adapt to the project can lead to even greater complications.
In the context of Swift, it is common to use groups such as Domain, App Data, Networking, Storage, and Features. The flexibility in defining these groups is a positive aspect highlighted in the book, allowing each project to determine the required number of groups without strict rules. It is important to emphasize that, regardless of the chosen groups, the Domain will always be present as an essential part of the architecture.
A crucial aspect of defining a group within the architecture is establishing which design patterns will be used, what problem the group seeks to solve, and which system unit it is integrating. The presence of the first and second groups is fundamental to build a consistent architecture, while the existence of the third group is optional, although it is the reason for the majority of the groups’ existence.
The last step involves establishing the interdependencies between the groups, resulting in the layered architectural structure. For example, the Domain group is a dependency of the App Data group, which in turn is a dependency of the Networking and Storage groups, while the Domain group is also a dependency of the Features group. This visualization may seem somewhat confusing to novice developers in the subject, especially when considering that SwiftUI and Storage are at the same architectural level as Networking and UIKit.
The goal is to understand the purpose of the graph that describes the individual dependencies of each group. For example, SwiftUI depends on Features, which in turn depends on Domain. Storage depends on AppData, which depends on Domain. Networking depends on AppData, which also depends on Domain. This is the correct way to interpret the graph.
In this alternative visual format, we are highlighting only the system units in which the architecture is embedded. By removing the visualization of the groups, we can identify that we have resources such as Networking, Storage, and Graphical User Interface (GUI) that the architecture relates to. From there, we can break down each system unit into groups and establish the layers as discussed earlier in this article.
Final thoughts
As a Swift developer, I recommend reading this book, not necessarily in every detail presented, but especially the parts that explain building an architecture from scratch. It is important to note that clean architecture is not related to modularization in Cocoapods or SPM, but rather to the independence of different parts of the software.
Personally, I have developed several applications exploring the concepts of clean architecture while using modularization to provide a more precise perspective.
Thank you for reading this far, and I hope this information proves useful to you 😉.
If you would like to contribute so that I can continue producing more technical content, please feel free to buy me a coffee ☕️ through the Buy me a Coffee platform.
Your support is essential to maintain my work and contribute to the development community.
