Clean Architecture layers in Android Kotlin - Mini App: Build & Ship

Build: Clean Architecture Demo

This screen demonstrates a simple app structured with Clean Architecture layers: Presentation, Domain, and Data. It shows a list of tasks fetched from a repository and allows adding a new task.

Target UI

-------------------------
| Clean Architecture Demo |
-------------------------
| Tasks:                 |
| 1. Buy groceries       |
| 2. Walk the dog        |
|                       |
| [Add Task]             |
-------------------------

Use three layers: Presentation (UI), Domain (business logic), Data (repository).

Presentation layer shows a list of tasks and an Add Task button.

Domain layer defines a UseCase to get tasks and add a task.

Data layer implements a repository with in-memory storage.

Add Task button adds a new task with a fixed name 'New Task'.

UI updates to show the new task after adding.

Starter Code

Android Kotlin

package com.example.cleanarchitecture

import android.os.Bundle
import androidx.activity.ComponentActivity
import androidx.activity.compose.setContent
import androidx.compose.foundation.layout.Column
import androidx.compose.foundation.layout.padding
import androidx.compose.foundation.lazy.LazyColumn
import androidx.compose.foundation.lazy.items
import androidx.compose.material3.Button
import androidx.compose.material3.MaterialTheme
import androidx.compose.material3.Surface
import androidx.compose.material3.Text
import androidx.compose.runtime.*
import androidx.compose.ui.Modifier
import androidx.compose.ui.unit.dp

// TODO: Define data layer repository interface and implementation

// TODO: Define domain layer use cases

// TODO: Define presentation layer UI

class MainActivity : ComponentActivity() {
  override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContent {
      MaterialTheme {
        Surface(modifier = Modifier.padding(16.dp)) {
          // TODO: Call the UI composable here
        }
      }
    }
  }
}

Task 1

Task 2

Task 3

Task 4

Task 5

Solution

Android Kotlin

package com.example.cleanarchitecture

import android.os.Bundle
import androidx.activity.ComponentActivity
import androidx.activity.compose.setContent
import androidx.compose.foundation.layout.Column
import androidx.compose.foundation.layout.padding
import androidx.compose.foundation.lazy.LazyColumn
import androidx.compose.foundation.lazy.items
import androidx.compose.material3.Button
import androidx.compose.material3.MaterialTheme
import androidx.compose.material3.Surface
import androidx.compose.material3.Text
import androidx.compose.runtime.*
import androidx.compose.ui.Modifier
import androidx.compose.ui.unit.dp

// Data Layer
// Task data class
data class Task(val id: Int, val name: String)

// Repository interface
interface TaskRepository {
  fun getTasks(): List<Task>
  fun addTask(task: Task)
}

// In-memory repository implementation
class InMemoryTaskRepository : TaskRepository {
  private val tasks = mutableListOf(
    Task(1, "Buy groceries"),
    Task(2, "Walk the dog")
  )

  override fun getTasks(): List<Task> = tasks.toList()

  override fun addTask(task: Task) {
    tasks.add(task)
  }
}

// Domain Layer
class GetTasksUseCase(private val repository: TaskRepository) {
  operator fun invoke(): List<Task> = repository.getTasks()
}

class AddTaskUseCase(private val repository: TaskRepository) {
  operator fun invoke(task: Task) {
    repository.addTask(task)
  }
}

// Presentation Layer
@Composable
fun TaskScreen(
  getTasksUseCase: GetTasksUseCase,
  addTaskUseCase: AddTaskUseCase
) {
  var tasks by remember { mutableStateOf(getTasksUseCase()) }

  Column {
    Text(text = "Tasks:", style = MaterialTheme.typography.titleMedium)
    LazyColumn(modifier = Modifier.padding(vertical = 8.dp)) {
      items(tasks) { task ->
        Text(text = "${task.id}. ${task.name}")
      }
    }
    Button(onClick = {
      val newTask = Task(tasks.size + 1, "New Task")
      addTaskUseCase(newTask)
      tasks = getTasksUseCase() // refresh list
    }) {
      Text("Add Task")
    }
  }
}

class MainActivity : ComponentActivity() {
  override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    val repository = InMemoryTaskRepository()
    val getTasksUseCase = GetTasksUseCase(repository)
    val addTaskUseCase = AddTaskUseCase(repository)

    setContent {
      MaterialTheme {
        Surface(modifier = Modifier.padding(16.dp)) {
          TaskScreen(getTasksUseCase, addTaskUseCase)
        }
      }
    }
  }
}

This solution uses Clean Architecture layers clearly separated:

• Data Layer: Defines Task data class and TaskRepository interface with an in-memory implementation InMemoryTaskRepository that stores tasks in a list.
• Domain Layer: Contains use cases GetTasksUseCase and AddTaskUseCase that interact with the repository to get and add tasks. This isolates business logic from UI and data.
• Presentation Layer: The TaskScreen composable displays the list of tasks and an Add Task button. It uses Compose state to update the UI when tasks change. Clicking the button adds a new task with a fixed name and refreshes the list.

This structure helps keep code organized, testable, and easy to maintain by separating concerns.

Final Result

Completed Screen

-------------------------
| Clean Architecture Demo |
-------------------------
| Tasks:                 |
| 1. Buy groceries       |
| 2. Walk the dog        |
| 3. New Task            |
|                       |
| [Add Task]             |
-------------------------

User sees a list of tasks with their numbers and names.

User taps 'Add Task' button.

A new task named 'New Task' is added to the list and displayed immediately.

Stretch Goal

Add a text input field to let the user enter a custom task name before adding.

💡 Hint

Use a TextField composable with state to capture input and pass it to AddTaskUseCase instead of a fixed name.

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