Clean Architecture

From Principles to Practice

Buzz words
• Separation of Concerns
• High-Level and Low-Level modules
• Coupling and Decoupling
• SOLID Principles
Separation of Concerns (SoC) is a design principle where
Separation program is divided into distinct sections each addressing a
specific concern or functionality.

of Concerns A Concern is a feature, behavior or responsibility of a system.

Each part of the system should focus on one concern without
overlapping responsibility. It makes system modular, easier to
maintain, and scalable.
• Example:
• AuthService, TransactionService etc.
• High-Level Modules: High-level module are components
responsible for orchestrating or defining the over all business
logic and workflows in system.

• Characteristics:

High-Level • They focus on “what” the system should do.

• They rely on abstraction rather than specific
implementations

and Low- • Low-Level Modules: Low-level modules are components that

Level deal with the details of implementation, such as interacting

with databases, APIs, or sending notifications.

Modules • Characteristics:
• They focus on “how” task are executed.
• They are specific implementation of abstract
contract/interfaces.
Coupled Design Decoupled
Design

Coupling
• Coupling: Coupling refers to the degree of dependency between two
modules or components in a system.

and
• Tight Coupling: Modules are heavily dependent on each other.
In other word changing in one module may require changes in
others.
• Loose Coupling: Modules have minimal dependency. Changes

Decoupling in one module have little impact on others.

• Decoupling: Decoupling is the process of reducing dependencies

between components making system easier to maintain.

• Techniques for decoupling:

• Use interface or abstractions,
• Apply Dependency Injection to inject dependencies,
• Follow Dependency Inversion principle.
A set of five design principles intended to improve
the maintainability, scalability, and flexibility of
object-oriented software. Each letter stand for
one principle.

1. Single Responsibility Principle

SOLID 2. Open/Close Principle

3. Liskov substitution Principle

principles 4. Interface Segregation Principle

5. Dependency Inversion Principle
1. Single Responsibility Principle (SRP)
A class should have only one reason to change. In other word
we can say a class should have one and only one
responsibility.

Each class should focus on a single task or functionality to

avoid coupling unrelated functionalities.

• Example:
• TransactionManager class should handle creating,
updating transactions
• ReportGenerator class should be responsible for
generating reports.
2. Open/Close Principle (OCP)
Software entities (class, module, functions) should be
open for extension but closed for modification.

You should be able to add new functionality to a class

without altering its existing code.

• Example:
• A PaymentProcessor class uses a
PaymentStrategy interface. Adding a new
payment method (e.g. PayPal) involves
creating a new implementation of
PaymentStrategy without changing
PaymentProcessor
3. Liskov Substitution Principle (LSP)
Subtype must be substitutable for their base types.

If a class is derived from another, you should be able to

replace instance of the base class with the derived class
without affecting a program’s behavior.

• Example:
• A BankAccount base has methods like deposit() and
withdraw(). A SavingAccount and CurrentAccount
class derived from bank account must implement
these method without altering expected behavior
(e.g., withdraw(), should not through unexpected
exceptions unless account-specific constraints are
met)
4. Interface Segregation Principle (ISP)
No client should be forced to depend on method it does
not use.

Create small focused interfaces rather than one large,

general-purpose interfaces. This avoid implementing
unnecessary methods.

• Example:
• Instead of a single BankService interface with
methods like tranferFunds(),
calculateInterest() and applyForLoan()
create separate interfaces such as
FundTranferService,
InterestCalculationService and LoanService
5. Dependency Inversion Principle (DIP)
High-level modules should not depend on low-level
modules; both should depend on abstractions.

User interface or abstractions to reduce dependency

on specific implementations. This promotes flexibility
and testability.

Example:
• A NotificationService depends on a
NotificationSenderInterface not on specific
implementations like
EmailNotificationSender or
SMSNotificationSender.
What is Clean Architecture?
• History
• In 1996 Robert C. Martin (Commonly known as Uncle Bob) introduced
Dependency Inversion Principle in SOLID principle.
• In 2012 Uncle Bob formalized these ideas in his book Clean Architecture: A
Craftsman's Guide to Software Structure and Design
• Definition
• An architectural pattern that emphasizes on independent layers.
• Designed for maintainability, scalability and testability.
• Key Characteristics
• Clear Separation of Concerns.
• Dependency Direction: Inner layers must not depend on outer layers.
Think of it like an onion. With outermost
layers that can easily be peeled off, without
damaging any of its insides.

Similarly, in Clean Architecture, the

outermost layers are the ones that change
most frequently, but since none of the inner
layers depends on it, they can easily be
swapped out and replaced.
• Problem Without Clean Architecture:
• Messy code: Difficult to debug or extend
• Rigid Structures: Hard to accommodate
Why Should changes
• Testing Challenges: Untestable core logic.
We Care? • Impact of Clean Architecture:
• Long-term maintainability.
• Easier feature updates.
• Seamless team collaboration.
Core Layers of Clean Architecture
1. Entities (Innermost Layer)

• Purpose: Represents the core logic and domain entities of the

system.
• Contains Entities (Business objects) and aggregates that
encapsulates the domain rules.

• Examples:
• Business models (e.g., User, Product, Order)
• Domain services (e.g., validations, calculation rules)
2. Application

• Purpose: Contains use cases and application-specific business rules.

• Manages the flow of data between entities and ensures that business
logic is applied to mobile specific concerns.

• Examples:
• Use cases
3. Interface Adapters

• Purpose: Acts as a bridge between the mobile-specific

frameworkes and the core application logic.
• Converts data between external formats (e.g., APIs responses,
Local storage) and internal models.

• Examples:
• Controllers/Presenters/ViewModels
• Data Mappers
4. Frameworks and Drivers (Outermost Layer)

• Purpose: This layer contains the external mechanism, including

mobile specific frameworks and services.

• Example:
• UI frameworks (e.g., Jetpack Compose, Swift UI)
• Libraires (e.g., Room, Core Data)
• Device Hardware and Services (e.g., GPS, Camera)
• APIs (e.g., Push Notification, Firebase)
Dependency Rules
The fundamental rule of Clean Architecture is the Dependency Rule:
• Inner layers must not depend on outer layers
• Dependencies should always point inward, towards the higher-
level policies.

This means:
• Frameworks and Drivers (Outermost layer) depends on
Interface Adapters.
• Interface Adapters depends on the Application layer.
• The Application layer depends on the Entities layer.
• The Entities layer depends on nothing.
Implementation
Q&A
Clean up your doubts ☺
Credits
• Book
Clean Architecture: A Craftsman's Guide to Software Structure and Design
• Link: https://amzn.eu/d/i2wRMjh

• Blogs
• Solid Principle in Pictures
• Link: https://medium.com/backticks-tildes/the-s-o-l-i-d-principles-in-pictures-b34ce2f1e898
• Clean Architecture
• Link: https://medium.com/@rudrakshnanavaty/clean-architecture-7c1b3b4cb181
• Clean Architecture for the rest of us
• Link: https://pusher.com/tutorials/clean-architecture-introduction

• Tools
draw.io: For flow chart designs
Plant UML(PUML): for uml designs
Thanks
Code Clean, Code Smart