Clean Architecture layers in Android Kotlin - Deep Dive

Overview - Clean Architecture layers

What is it?

Clean Architecture layers organize an app into separate parts, each with a clear job. This helps keep code easy to understand and change. The main layers are Entities, Use Cases, Interface Adapters, and Frameworks & Drivers. Each layer talks only to the one next to it, making the app flexible and testable.

Why it matters

Without Clean Architecture, apps become tangled and hard to fix or add features. Changes in one part can break others unexpectedly. Clean Architecture solves this by separating concerns, so developers can work on one part without worrying about the rest. This leads to better apps that last longer and are easier to improve.

Where it fits

Before learning Clean Architecture layers, you should know basic Kotlin and Android app structure. After this, you can learn about dependency injection and advanced testing. Clean Architecture is a foundation for building solid, maintainable apps.

Mental Model

Core Idea

Clean Architecture layers separate app responsibilities so each part can change independently without breaking others.

Think of it like...

Imagine a restaurant kitchen where chefs, waiters, and suppliers each have their own space and tasks. Chefs cook, waiters serve, and suppliers deliver ingredients. They communicate only through clear handoffs, so the kitchen runs smoothly even if one part changes.

┌─────────────────────────────┐
│      Frameworks & Drivers    │
│  (UI, Database, Network)     │
└─────────────┬───────────────┘
              │
┌─────────────▼───────────────┐
│     Interface Adapters       │
│  (Presenters, Controllers)   │
└─────────────┬───────────────┘
              │
┌─────────────▼───────────────┐
│         Use Cases            │
│  (Business Logic, Services)  │
└─────────────┬───────────────┘
              │
┌─────────────▼───────────────┐
│          Entities            │
│  (Core Business Objects)     │
└─────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Entities Layer

Concept: Entities represent the core business data and rules independent of any technology.

Entities are simple Kotlin classes or data classes that hold important business information. They do not depend on Android or any framework. For example, a User entity might have properties like id, name, and email, and rules like validating email format.

Result

You get a clear, reusable model of your app's main data that can be used anywhere without change.

Understanding Entities helps you keep your core data safe from changes in UI or database technology.

2

Foundation

Role of Use Cases Layer

Concept: Use Cases contain the app's business logic and coordinate Entities to perform tasks.

Use Cases are Kotlin classes or functions that implement specific actions like 'Login User' or 'Fetch Orders'. They use Entities and apply rules to achieve goals. They do not know about UI or databases, only about the business process.

Result

Your app's important actions are centralized and testable without UI or database dependencies.

Knowing Use Cases separates what your app does from how it looks or stores data.

3

Intermediate

Interface Adapters Explained

🤔Before reading on: do you think Interface Adapters directly access Entities or Frameworks? Commit to your answer.

Concept: Interface Adapters convert data between Use Cases and external layers like UI or database.

This layer includes Presenters, ViewModels, and Controllers. They take data from Use Cases and prepare it for display, or take user input and convert it for Use Cases. They act as translators between business logic and technology.

Result

Your UI and database can change without affecting business logic, thanks to this translation layer.

Understanding Interface Adapters helps you isolate UI changes from core app logic.

4

Intermediate

Frameworks & Drivers Layer Role

🤔Before reading on: do you think Frameworks & Drivers contain business logic or just technical details? Commit to your answer.

Concept: This layer holds all external tools like Android UI, databases, and network libraries.

Frameworks & Drivers include Activities, Fragments, Room database, Retrofit network calls, and other platform-specific code. They depend on Interface Adapters but not on Use Cases or Entities directly.

Result

Your app can swap out UI or database tools without rewriting business rules.

Knowing this layer keeps your app flexible and ready for technology changes.

5

Intermediate

Dependency Rule in Layers

Concept: Dependencies always point inward, from outer layers to inner layers.

In Clean Architecture, outer layers like Frameworks & Drivers depend on Interface Adapters, which depend on Use Cases, which depend on Entities. Inner layers never depend on outer layers. This keeps core logic safe from external changes.

Result

Your app's core business logic remains stable even if UI or database code changes.

Understanding dependency direction prevents accidental tight coupling and fragile code.

6

Advanced

Applying Clean Architecture in Android

🤔Before reading on: do you think Activities should contain business logic in Clean Architecture? Commit to your answer.

Concept: In Android, Activities and Fragments belong to Frameworks & Drivers, not business logic.

Use ViewModels in Interface Adapters to communicate with Use Cases. Use Cases call Entities. Data flows inward and results flow outward. This separation improves testability and maintainability.

Result

Your Android app has clear boundaries, making it easier to test and update UI or business rules independently.

Knowing Android roles in layers helps you organize code for long-term success.

7

Expert

Handling Data Flow and Boundaries

🤔Before reading on: do you think data can flow from Entities directly to Frameworks? Commit to your answer.

Concept: Data flows inward as requests and outward as responses, crossing boundaries via interfaces.

Use interfaces and dependency inversion to let inner layers define contracts. Outer layers implement these contracts. This allows swapping implementations without changing core logic. For example, Use Cases define repository interfaces; Frameworks provide database implementations.

Result

Your app can replace databases or network layers without touching business logic, enabling easier upgrades and testing.

Understanding boundary crossing and inversion of control is key to mastering Clean Architecture.

Under the Hood

Clean Architecture works by enforcing strict dependency rules at compile time. Inner layers define interfaces that outer layers implement. Kotlin's interface and class system supports this. The app runs by passing data inward through interfaces and returning results outward, ensuring core logic never depends on UI or database code.

Why designed this way?

It was designed to solve the problem of tightly coupled code that breaks easily. By separating concerns and controlling dependencies, developers can change UI or data storage without risking core business logic. This approach evolved from decades of software engineering best practices.

┌───────────────┐
│ Frameworks &  │
│ Drivers (UI,  │
│ DB, Network)  │
└───────┬───────┘
        │ implements
┌───────▼───────┐
│ Interface     │
│ Adapters      │
│ (ViewModels,  │
│ Presenters)   │
└───────┬───────┘
        │ calls
┌───────▼───────┐
│ Use Cases     │
│ (Business    │
│ Logic)        │
└───────┬───────┘
        │ uses
┌───────▼───────┐
│ Entities      │
│ (Core Models) │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think UI code should contain business rules? Commit yes or no.

Common Belief: UI components like Activities should handle business logic for simplicity.

Reality: Business logic belongs in Use Cases, not UI, to keep code clean and testable.

Why it matters: Mixing UI and business logic makes apps hard to maintain and test, causing bugs when UI changes.

Quick: Do you think Entities depend on database or network code? Commit yes or no.

Common Belief: Entities often include database or network details for convenience.

Reality: Entities must be independent of any technology to stay reusable and stable.

Why it matters: Tying Entities to technology makes changing databases or APIs risky and costly.

Quick: Do you think dependencies can point outward from Entities? Commit yes or no.

Common Belief: Dependencies can go any direction as long as code works.

Reality: Dependencies must always point inward to protect core logic from outer changes.

Why it matters: Wrong dependency direction causes fragile code that breaks easily when UI or database changes.

Quick: Do you think Clean Architecture is only for big projects? Commit yes or no.

Common Belief: Clean Architecture is too complex for small apps and only suits large projects.

Reality: Even small apps benefit from clear separation to avoid early technical debt.

Why it matters: Skipping architecture in small apps leads to messy code that grows harder to fix over time.

Expert Zone

1

Use Cases should be pure Kotlin without Android dependencies to maximize testability and reuse.

2

Interface Adapters often use data mappers to convert between Entities and UI models, a subtle but crucial detail.

3

Dependency inversion requires careful interface design to avoid leaking implementation details inward.

When NOT to use

Clean Architecture can be overkill for very simple apps or prototypes where speed matters more than maintainability. In such cases, simpler MVC or MVVM patterns may be better.

Production Patterns

In real apps, teams use dependency injection frameworks like Hilt to manage layer dependencies. They write unit tests for Use Cases and Entities, and UI tests for Frameworks. Layers are often in separate modules to enforce boundaries.

Connections

SOLID Principles

Clean Architecture builds on SOLID principles, especially Dependency Inversion and Single Responsibility.

Understanding SOLID helps grasp why Clean Architecture separates layers and controls dependencies.

Hexagonal Architecture

Clean Architecture is a form of Hexagonal Architecture with clear ports and adapters.

Knowing Hexagonal Architecture clarifies the role of Interface Adapters as ports connecting inner logic to outer systems.

Organizational Structure Theory

Layered architecture in software mirrors organizational layers in companies for clear roles and communication.

Seeing software layers like company departments helps understand why separation and clear interfaces reduce confusion and errors.

Common Pitfalls

#1 Putting business logic inside Activities or Fragments.

Wrong approach:

class MainActivity : AppCompatActivity() {
fun login() {
if (email.isEmpty()) showError()
else callApi()
}
}

Correct approach:

class LoginUseCase {
fun execute(email: String) {
if (email.isEmpty()) throw Error("Email empty")
// business logic here
}
}

class MainActivity : AppCompatActivity() {
val loginUseCase = LoginUseCase()
fun login() {
try {
loginUseCase.execute(email)
} catch (e: Error) {
showError()
}
}
}

Root cause:

Confusing UI code with business logic leads to mixing concerns and fragile code.

#2 Entities depending on Android classes like Context or View.

Wrong approach:

data class User(val name: String, val context: Context)

Correct approach:

data class User(val name: String)

Root cause:

Not isolating core data from platform details breaks reusability and testability.

#3 Allowing dependencies from Entities to Frameworks layer.

Wrong approach:

class UserEntity {
fun saveToDatabase(db: RoomDatabase) { /* ... */ }
}

Correct approach:

interface UserRepository {
fun save(user: UserEntity)
}

class RoomUserRepository : UserRepository {
override fun save(user: UserEntity) { /* ... */ }
}

Root cause:

Violating dependency rules causes tight coupling and hard-to-maintain code.

Key Takeaways

Clean Architecture divides an app into layers with clear responsibilities to keep code organized and flexible.

Entities hold core business data and rules, independent of UI or database technology.

Use Cases implement business logic and coordinate Entities without knowing about UI or frameworks.

Interface Adapters translate data between Use Cases and external layers like UI and databases.

Frameworks & Drivers contain platform-specific code and depend on inner layers, never the other way around.

Practice

1. Which layer in Clean Architecture is responsible for business rules and logic?
domain, data, or presentation?

easy

A. Presentation layer

B. Domain layer

C. Data layer

D. UI layer

Solution

1. Step 1: Understand the role of each layer

   The domain layer contains business rules and logic, independent of UI or data sources.

2. Step 2: Match the layer to its responsibility

   Since business logic is in the domain layer, it is the correct answer.

3. Final Answer:

   Domain layer -> Option B

4. Quick Check:

   Business logic = Domain layer [OK]

Hint: Business rules live in domain layer, not UI or data [OK]

Common Mistakes:

• Confusing data layer with domain layer
• Thinking UI handles business logic
• Mixing presentation with domain

2. Which Kotlin syntax correctly defines a repository interface in the domain layer?

?

easy

A. interface UserRepository { fun getUser(id: Int): User }

B. class UserRepository { fun getUser(id: Int): User }

C. fun UserRepository() = User()

D. val UserRepository = object { fun getUser() = User() }

Solution

1. Step 1: Identify interface syntax in Kotlin

   Interfaces use the keyword interface followed by function signatures without bodies.

2. Step 2: Check each option

   interface UserRepository { fun getUser(id: Int): User } correctly declares an interface with a function signature. Others define classes or objects incorrectly for an interface.

3. Final Answer:

   interface UserRepository { fun getUser(id: Int): User } -> Option A

4. Quick Check:

   Kotlin interface syntax = interface UserRepository { fun getUser(id: Int): User } [OK]

Hint: Interfaces use 'interface' keyword with function signatures [OK]

Common Mistakes:

• Using class instead of interface for repository
• Defining function bodies inside interface
• Using val or fun incorrectly for interface

3. Given this code snippet in the data layer:

class UserRepositoryImpl(private val api: UserApi) : UserRepository {
  override fun getUser(id: Int): User {
    return api.fetchUser(id)
  }
}

What does getUser(5) return?

medium

A. Null because fetchUser returns nothing

B. An error because UserRepositoryImpl lacks a constructor

C. A User object fetched from the API with id 5

D. A compile-time syntax error

Solution

1. Step 1: Understand class and method behavior

   UserRepositoryImpl implements UserRepository and calls api.fetchUser(id) to get a User.

2. Step 2: Analyze getUser(5) call

   Calling getUser(5) returns the User object fetched by api.fetchUser(5), assuming api works correctly.

3. Final Answer:

   A User object fetched from the API with id 5 -> Option C

4. Quick Check:

   Method calls API and returns User [OK]

Hint: Implementation calls API method and returns result [OK]

Common Mistakes:

• Assuming missing constructor causes error
• Thinking fetchUser returns null by default
• Confusing syntax errors with runtime behavior

4. Identify the error in this presentation layer code snippet:

class UserViewModel(private val repo: UserRepository) {
  fun loadUser(id: Int) {
    val user = repo.getUser(id)
    println(user.name)
  }
}

medium

A. UserViewModel should not call repository directly

B. User object might be null causing a crash

C. No error; code is correct

D. UserRepository interface is not implemented

Solution

1. Step 1: Recall Clean Architecture dependencies

   The presentation layer (ViewModel) should depend on use cases in the domain layer, not directly on repository interfaces.

2. Step 2: Identify the violation

   Directly injecting and calling UserRepository in ViewModel bypasses use cases, mixing concerns and violating layer separation.

3. Final Answer:

   UserViewModel should not call repository directly -> Option A

4. Quick Check:

   ViewModel -> UseCase -> Repository [OK]

Hint: ViewModels call UseCases, not Repositories directly [OK]

Common Mistakes:

• Focusing on null safety (type system prevents null here)
• Thinking no architecture error in the code
• Assuming missing interface implementation

5. You want to add caching to your app using Clean Architecture. Where should the cache logic be placed?
Options:
A) In the domain layer
B) In the data layer
C) In the presentation layer
D) In the UI components

hard

A. Domain layer to keep business rules

B. UI components for faster display

C. Presentation layer to update UI directly

D. Data layer to manage data sources including cache

Solution

1. Step 1: Understand caching responsibility

   Caching is a data management concern, related to how data is stored and retrieved.

2. Step 2: Match caching to Clean Architecture layer

   The data layer handles data sources like network, database, and cache, so caching logic belongs here.

3. Final Answer:

   Data layer to manage data sources including cache -> Option D

4. Quick Check:

   Cache logic = Data layer [OK]

Hint: Cache belongs in data layer managing data sources [OK]

Common Mistakes:

• Putting cache in domain layer (business logic)
• Adding cache in UI or presentation layers
• Mixing UI concerns with data management