Deconstructing Clean Architecture

As an Android app developer, if you've ever created multiple folders, filled them with dozens of classes in Java or Kotlin — and then paused to wonder what it all means — congratulations! You’ve arrived at the right place in your journey toward Android nirvana.

In this blog, we’ll explore how to amalgamate Clean Architecture into your Android app to make it scalable, testable, and less error-prone. But before diving into the Kotlin code and Compose UI, let’s pause and ask the first real questions:

🧠 What is Clean Architecture?

🛠️ How does it fit into the Android ecosystem?

Let’s answer these with clarity and confidence — and then build a sleek News App to bring everything together, layer by layer, creating architectural magic.

What is Clean Architecture ?

At its core, Clean Architecture is a way of organising your app so that the business logic is completely independent from Android frameworks like Android, Retrofit, Room, or even the UI layer.

Imagine that we are building a new app where we can :

• Swap XML with Jetpack Compose without rewriting business logic.

• Swap Room with Firebase without touching the use-cases.

• write tests and they would still not what Android actually is.

That is the power of clean architecture - decoupling.

Goal of Clean Architecture

The idea popularised by Robert C.Martin (Uncle Bob) is based on the following principle - Dependencies must always point inwards.

This means :

• The UI layer can depend on the use-cases.

• The use-cases can depend on entities (core business model).

• But nothing should depend on the UI, or Room, or Retrofit.

Let us try to understand further with the concentric layered diagram below:

At its core, Clean Architecture is all about separation of concerns, independence, and dependency inversion.

That means:

• Inner circles define "what" the system does.

• Outer circles define "how".

• Arrows of dependency always point inward.

Layer 1: Entities (Center)

• Most stable and abstract part of the system.

• Consists of core business objects and rules.

• Independent of use cases, frameworks, UI, or even applications.

Examples: User,Article,Transaction

It consists of business rules like: canUserAcceptCredit(user)

In Android Terms:

• Pure Kotlin data classes or interfaces

• No Android dependencies

• Reusable across platforms (can even move to shared modules)

• Change in the entities is rare. They are the heart of the system.

Layer 2: Use Cases (Application Business Rules)

• Consists of application-specific rules.

• This layer knows about entities.

• Uses entities to accomplish a task.

• Coordinate the flow of data to and from entities

• Contain application logic (e.g., GetTopHeadlinesUseCase)

• It does not know about UI, frameworks or databases

Layer 3: Interface Adapters

• Converts data between the format the use cases expect and the format the frameworks use.

• Also known as Presenters, Controllers, Gateways, or ViewModels.

Examples:

• A ViewModel that calls a UseCase and exposes LiveData or StateFlow

• DTO to Entity and vice-versa mappers.

• Repositories implementations talking to APIs or DB

In Android terms:

• Jetpack ViewModel, Mappers, Adapter classes

• Converts between UIState and DomainModel (vice-versa as well)

Goal:

• Act as glue — transforming data as it moves in and out of the system

Layer 4: Frameworks & Drivers

• It is the outermost layer — frameworks, devices, libraries, and technologies.

• Includes things we do not own and do not control.

Examples:

• Retrofit, Room, Firebase, Android SDK, Jetpack Compose, Hilt, CameraX

In Android terms:

• Activity, Fragment, Navigation, Hilt modules

• DB schema, Retrofit APIs, network serializers

Goal:

• Plug-and-play — can be replaced without affecting the inner core

• Know nothing about business logic

DEPENDENCY RULE

Golden rule:

Inner layers know nothing about the outer layers.

This means:

• Entities know nothing about UseCases

• UseCases know nothing about ViewModels

• ViewModels know nothing about Activities/Fragments

• Repositories are interfaces in domain, implemented in data