Clean Architecture with Dependency Rule

Published in

Design Microservices Architecture with Patterns & Principles

7 min readFeb 15, 2023

In this article, we are going to learn Clean Architecture and Dependency Rule when designing any software architecture for our projects.

By this article, we are going to learn Clean Architecture, Benefits and Challenges of Clean Architecture and Design our E-Commerce application with Clean Architecture.

I have just published a new course — Design Microservices Architecture with Patterns & Principles.

Architecture Design Journey

There are many approaches and patterns that evolved over decades of software development, and all have their own benefits and challenges.

In the last article, we have learned and designed e-commerce application with Layered Architecture style. Now we will focus on how it can be better organize layers with Clean Architecture in order to provide isolation.

Why we are learning Clean Architecture ?

Because according to our learning flow, we ask ourselves

What’s wrong with this current architecture ?
How can we improve the current design ?

With these questions we created a problem about Layered architecture and try to solve this problem during the article. Problem is Highly Coupling Dependent Layers:

And as a solution we have decided to learn Clean Architecture with the Dependency Rule principle. The idea is provide flexibility and testability features in our current architecture.

So that means with Clean Architecture, we will extend our N-FRs; flexibility and testability. As you remember that with Layered Architecture and SoC we have provide Code Organization and Maintainability. So now with Clean Architecture, we will provide flexibility and testability. By the way, We are still in Monolithic architecture styles, but you can think that we are learning sub architectures of monolithic architecture like layered — clean — hexagonal and so on.

What is Clean Architecture

Clean architecture is the most commonly used architecture pattern in software engineering. It is a software design practice that separates the elements of a design into circle levels. Clean architecture was created by Robert C. Martin and promoted on his blog, Uncle Bob.

Clean architecture is provide to organize code with encapsulates the business logic into inner circles without any dependencies and separate the implementation codes from outer circles. So that means to keep the core business logic and application domain at the center of the solution structure. So we develop core application business logics and domain objects at the core of our architecture and independent with presentation and data access layers.

This will provide to flexibility of changing technology and interfaces. Additionally, the core application remains the same and independent of presentation layers, infrastructures, and databases. The main goal of Clean Architecture is to create software systems that are easy to maintain, test, and evolve over time, while also being robust, flexible, and adaptable to changing requirements.

Basically, Clean architecture divided into two main elements: the policies and the details. The policies are the business rules and procedures, and the details are the implementation code to carry out the policies.

In the clean architecture, it is not necessary to choose the database or framework at the beginning of the development, instead its focus on the policies and business logics that build on project requirements and after that implement those policies in outer layers with applying different technology stack, libraries and frameworks. You can see the image of Clean Architecture:

The internal layers contains the business rules and has not dependency of any third-party library, which allows to use different frameworks and tools and not to lock any library if the technology is changed. So the outer layers contains actual implementation with dependency of inner layers and 3rd party tools.

The Dependency Rule

At this point we should learn the main principle of Clean Architecture which is The Dependency Rule. The Dependency Rule says that the dependencies of a source code can only point inwards, that means code dependencies can only move from the outer levels inward.

Code on the inner layers can have no knowledge of functions on the outer layers. Inner layer cannot have any information about elements of an outer layer. Classes, functions, variables, data format, or any entity declared in an outer layer must not be mentioned by the code of an inner layer. It is also recommended that data formats also stay separate between levels.

Layers of Clean Architecture

At the core of Clean Architecture is the idea of separating the code into layers, with each layer having a specific responsibility and purpose. These layers include:

Domain Layer: This layer contains the core business logic and rules of the application. It should be independent of any specific framework or technology and should define the essential domains and business rules of the system.
Use Case Layer: This layer contains the application-specific use cases, which are the actions that can be performed by the system. It should depend on the Domain Layer but should not depend on any external technology or framework.
Interface Layer: This layer contains the interfaces for the application, such as the user interface or web API. It should depend on the Use Case Layer but should not depend on the Domain Layer or any external technology.
Infrastructure Layer: This layer contains the implementation details of the application, such as the database or external APIs. It should depend on all other layers but should not be dependent on any specific framework or technology. This is the outermost layer in this clean architecture which changes frequently based on the technologies, updates like database, Web Front-end frameworks.

Benefits of Clean Architecture

Clean Architecture provide to design applications with very low dependency connections and independent of technical implementation details, such as databases and frameworks. By this way, the application becomes easy to maintain and flexible to change. The benefits that clean architecture brings to us:

Independent of Database and Frameworks
The software is not dependent on an ORM or Database. You can change them easily.
Independence of UI
The UI can change easily, without changing the rest of the system and business rules.
Testable
It is naturally testable. You can test business rules without considering UI, Database, Mock servers, etc.
Independence of any external agency
In fact, your business rules simply don’t know anything at all about the outside world.

When to use Clean Architecture ?

Clean Architecture is particularly useful in situations where you need to build a system that is expected to be highly flexibility, testable, and adaptable over time. Here are some specific scenarios where Clean Architecture can be beneficial:

Large or complex software projects: When you are working on a large or complex software project, it can be challenging to manage the code and ensure that it remains maintainable and testable over time. Clean Architecture provides a structured approach to organizing the code that can help to mitigate these issues.
Applications that require frequent updates or changes: If you are building an application that is expected to undergo frequent updates or changes, Clean Architecture can make it easier to implement these changes without causing problems elsewhere in the system.
Applications that need to be highly testable: Clean Architecture can help you to build an application that is highly testable, reducing the risk of bugs and making it easier to diagnose and fix issues that do arise.

Drawbacks of Clean Architecture

While Clean Architecture provides many benefits for software development, there are also some potential drawbacks to consider. Here are some of the most common ones:

Initial setup and learning curve: Clean Architecture can require some extra setup time and a learning curve for developers who are new to the approach. This may add some initial overhead to the project.
Over-engineering: It is possible to over-engineer a software system by trying to apply the Clean Architecture principles too rigidly. This can lead to overly complex code that is difficult to understand and maintain.
Added complexity: Clean Architecture can add some additional complexity to a project, particularly when it comes to managing the interactions between different layers of the system.

Design Clean Architecture — E-Commerce App

If we design e-commerce application with Clean architecture, you can see the image below:

There is a big single Monolithic Application Server but Application has Clean Architecture layers which’s are Domain, Application, Infrastructure and Web UI. And there is one big relational databases.

Design Microservice Architecture — E-Commerce App

If we design e-commerce application with Microservice architecture, you can see the image below:

Product microservice can use NoSQL document database Shopping Cart microservice can use NoSQL key-value pair database and Order microservice can use Relational database as per microservice data storage requirements.

What’s Next ?

Step by Step Design Architectures w/ Course