Computer systems are becoming more and more essential to society. Software is used for everything, from everyday tasks like ordering food over the phone to imaging exams. Software is used to meet this increasing demand. It must be produced and maintained at the correct costs. This will allow for its growth and optimization while not compromising existing software.
Software engineering is an engineering discipline that deals with all aspects of software production. It includes the specification, development validation, evolution, and validation of software. Software engineering is simplified because the software does not have to be restricted by physical laws. This simplification allows developers to create applications optimally. However, the software can become complex and challenging to maintain if there is an insufficient constraint.
Software buildings, unlike physical facilities, are composed of smaller parts like brick, concrete, or wood. Both types of buildings also have the architecture to support their structure and keep it secure and stable. Software architecture is a crucial concept in software engineering. Software architecture is the overall structure of a program or computer system. It includes the software components, their externally visible properties, and the relationships among them.
Software development is constantly changing. Good architecture helps to minimize the time it takes to make these changes. This reduces costs and effort. Architecture must meet the immediate needs of developers, owners, and users and fulfill these expectations over time (MARTIN 2017).
There are many architectural styles in building architecture, such as romantic, classic, and extravagant, so too there are several architectural types in software architecture. Every software architecture shares the common goal of dividing the software into layers. Each layer should have at least one to support business rules and one to keep the user and system interfaces.
Architecture must meet the needs of developers and users at a particular time and their expectations over time. We proposed Clean Architecture to promote coherent systems independent of technology and encourage code reuse. We’ll then examine this architecture in more detail.
Clean Architecture
Clean Architecture in his book “Clean Architecture: a Craftsman’s guide to software structure and design”. The architecture can be broken down into two major elements, the policies and details. The details are the necessary items to implement the policies. Clean Architecture can distinguish itself from other architectural patterns from this division. The system must recognize the policy elements as the core of the architecture and ignore the details.
Clean architecture does not require that you choose the framework or database at the beginning of development. These details do not necessarily interfere with policies and can be modified over time.
Layer Division
Clean Architecture has a clearly defined division of layers. The architecture is framework-independent, i.e., the internal layers that contain the business rules do not depend on any third-party library, which allows the developer to use a framework as a tool and not adapt the system to meet the specifications of a particular technology. Clean Architecture also offers testability, UI independence and database independence.
Each layer of the figure represents a different part of the software. The innermost is the policies, and the outermost are the mechanisms.
Clean Architecture’s main rule is the Dependency Rule. This states that dependencies in a source code cannot point inwards. That is, they must only point toward the highest-level policies. Elements in an innermost layer cannot contain information about elements in an outermost layer. The code of an inner layer cannot mention classes, functions, variables, data formats, or any entity declared within an outer layer.
The Entities layer is the innermost layer. It contains the application’s business goals and has the most basic and highest-level rules. An entity can include data structures, functions, or objects with methods. As long as multiple apps can use it, an entity can exist. This layer should not be affected by any changes to the outermost layers.
The use case layer comprises application-specific business rules that group and implement all use cases. Use cases are responsible for organizing the data flow to and from entities. They also guide entities in applying business rules to meet their use case goals. Your changes to the entities layer should not also affect this layer. If the details of a case change, however, some code within that layer may be affected.
A set of adapters is included in the interface adapters layer. These adapters convert data to the most suitable format for the surrounding layers. It takes data from a database and converts it into the most convenient format for entity layers and use cases. You can also reverse the process of converting data, moving it from the innermost to the outermost layers. This layer includes controllers, presenters, views, as well as controllers.
Frameworks and databases are often found in the outermost layer of a diagram. This layer comprises the code that establishes communication between the interface adapters layer. This layer contains all the details, the web is one detail and the database another. All these elements are placed in the outermost layer to avoid interfering with others.
However, if these layers are independent, how can they communicate with each other? The Dependency Inversion Principle solves this contradiction. It explains how you can arrange the inheritance relationships and interfaces, so that source code dependencies are opposite to the control flow at all points.
A use case must communicate with the presenter. This call is not straightforward because it would violate the Dependency Rule. The use case calls the interface from the inner layer, and the presenter in the outer circle implements it. This technique can be used across all layers of architecture. Data that travels between layers can be simple structures or basic data transfer objects. These data are just arguments for function calls. To avoid violating the Dependency Rule, entities or records must not be transmitted.
Conclusions
Architecture is not the panacea that solves all problems. It’s not Clean Architecture who came up with this.
Clean Architecture is a tool that allows you to keep the application updated and evolving after it has been built. Clean Architecture’s layers can be independently managed and made more accessible by the consistent application of design patterns. Changes to one part of the system do not affect the operation of others.
A more experienced team of developers will be needed to work on the system. To maintain and structure the software, you need to have a good understanding of design patterns. Seeing the first results in an MVP application takes more time than a simple MVP app. It is essential to have strong client alignment so that the future benefits are clear.
Clean Architecture is an ideal solution for applications that are likely to continue growing over time. For simple, non-evolving systems, however, the Clean Architecture approach may not be worthwhile. It is better to stick with simpler architectural patterns.
