What is Clean Architecture? Do you need it?
While designing an application solution, it is necessary to organize our solution in such a way that the code is maintainable, extensible and testable.
The way we design our solution also reflects in how the application works for client requests.
As application grows and new functionalities are added, the solution grows in size with new files and can result in less efficient design.
This is where we apply some of the most used architectural patterns.
What is a Monolithic Architecture?
While beginning an application, developers tend to place all the functional code inside a single project which we call a Monolith.
This solution contains all the business, presentation and persistence logic within it.
A Monolith is the simplest — it is entirely self-contained in terms of behavior. Though an application may interact with other data sources or invokes other services for its functionality, the core behavior is contained within the solution and is deployed as a single unit.
A Monolith application is generally scaled horizontally, meaning the binaries are replicated into multiple servers or virtual machines when needed to handle high demand.
What is an N-Layer Monolith?
A traditional N-Layer monolith is a little better organized over the 1-tier Monolith. It is designed by splitting a single project into multiple tiers, or layers.
A single solution may contain -
* User Interface Layer or Presentation Layer
* Business Logic Layer
* Data Access Layer
Each of these layers (or tiers) are stacked one above the other and the control goes linearly through these layers.
Although convenient, this design is hard to test because to test any component in the Business Layer we need to create a Test database because of the tight coupling.
An alternative to this design is the Onion Architecture, also called
Clean Architecture — What is it?
In a Clean Architecture, the solution is designed with the Application Core at the center and the UI and Persistence depending on the Core.
The Application Core defines the required abstractions, that the Infrastructure layer implements and the UI layer uses to call functionalities.
This way, the interactions happen via abstractions defined in the Core layer following Dependency Inversion principle. The three layers are placed around one another line peels of an onion, hence the name Onion Architecture.
The advantage is that, any layer can be replaced with another implementation and the whole solution would still function without an issue. This is because the dependency is now not linear, but is based on abstractions.
Should you go with a Clean Architecture?
Choosing an architecture is a design choice, each application works in different ways and it is wise to choose a design based on the need. If you are building a very simple microservice that does a very simple job, putting up all these layers may be an overkill for you.
On the other hand, using a monolith for a very large solution is equally difficult. Choose a Clean Architecture design for your application, if you are completely sure about how your application would grow over the time.
You can easily decouple and build a Clean Architecture for your next .NET 6 application, with the libraries provided by the framework.
