What is clean architecture and why you should use it?

Introduction

Being a developer, have you ever written code that

• Is hard to understand because its intent or purpose was not clear?
• Has logics mixed?
• Is hard to debug?
• Is compiling fine but full of logical bugs?
• Painful to test?

If the answer is “Yes I have”, you are reading the right blog.

Being progressive developers, we learn various software design patterns and beyond that from the GoF Book and a variety of sources. We make deliberate efforts to implement solid principles as we code. All this has always helped us confront the above issues but only to a certain extent. We still see data access and business logic put in controllers, domain models being used everywhere and not being able to test the code without a database and we always feel the scope of improvement in the code.

The solution to all these common development issues is implementing “Clean Architecture” in our code.

Clean architecture is a concept proposed by Uncle Bob in his book Clean Architecture as a way of building highly flexible and maintainable software solutions

What is Clean Architecture?

“Dependency Rule” is the heart of “Clean Architecture” stating that source code dependency can only point inwards towards the application core.

This architecture has been called many names over the years, first name was Hexagonal Architecture, followed by Ports-and-Adapters. Until recently, it’s been cited as the Onion Architecture or Clean Architecture.

Applications that follow the Dependency Inversion Principle as well as the Domain-Driven Design (DDD) principles tend to arrive at a similar architecture and normally contain the following layers:

• Domain Layer
• Application Layer
• Data Layer
• IoC Layer
• Presentation Layer
• Test Layer

How it works?

Clean architecture puts the business logic (Application) and application model (Domain) at the centre of the application together called as Core.

The Core has to be completely independent of data access and other infrastructure concerns, so we invert the dependencies. This is achieved by adding interfaces or abstractions in Core that are implemented by layers outside of Core. For example, we need to implement the Repository Pattern we would add an interface within Core and add the implementation within Infrastructure.Data.

All dependencies flow inwards and Core has no dependency on any other layer. 

Infrastructure.Data and Presentation depend on Core, but not on one another.

How to implement this?

• Domain: Contains Entities (Business Models) and Repository Interfaces.
• Application: Contains Service Interfaces and their Services, DTOs (Data Transfer Objects) and View Models.
• Data: Contains EF Core types (DbContext, Migration), Data access implementation types (Repositories),Infrastructure-specific services (for example, FileLogger or SmtpNotifier).
• Infrastructure.IoC: Contains Dependency Container class to help implement Dependency Inversion.
• User Interface Types: Includes Controllers, Filters, Views, Startup.
• Tests Types: Includes Unit Tests, Integration Tests.

What are the Benefits of Clean Architecture?

• Framework Independent – You can use clean architecture with ASP.NET (Core), Java, Python, etc. It doesn’t rely on any software library or proprietary codebase.
• Database Independent-Majority of your code has no knowledge of what database, if any, is being used by the application. Often, this info will exist in a single class, in a single project that no other project references.
• UI Independent-The UI project cares about the UI only. It has nothing to do with the implementation of business or data logic.
• Highly Testable– Apps built using this approach, and especially the core domain model and its business rules, are extremely testable.

Source: https://www.planetecomsolutions.com/blog/what-is-clean-architecture-and-why-you-should-use-it/