Back

Understanding the Layers of Clean Architecture

Mukul J. · 16 April 2021

Clean Architecture typically consists of three main layers: Data, Domain, and Presentation, each with distinct responsibilities and dependencies.

Data Layer

The data layer is responsible for data operations and external interactions. It includes:

• Data Sources: Network APIs, local databases, and file storage
• Repositories: Implementations of repository interfaces defined in the domain layer
• Data Models: Objects that represent data from external sources
• Mappers: Convert between data models and domain entities

This layer handles all data-related operations like fetching from the network, storing in a local database, or caching data in memory. It’s a good practice to define separate data sources for network and database operations to maintain clear separation of concerns.

For example, in a News app, you might implement an in-memory cache to preserve data between screen navigations. When a user opens the news screen, the app first checks the cache for previously fetched news. If available, it displays the cached data immediately while refreshing in the background. If not, it fetches fresh data from the network.

For thread safety when managing cached data, you can use synchronization mechanisms like Mutex from Kotlin Coroutines. This ensures that concurrent access to shared resources doesn’t lead to race conditions.

Domain Layer

The domain layer is the core of your application, containing the business logic and rules. It is independent of other layers and defines the core business entities, use cases, and interfaces that the application needs. This layer contains:

1. Entities: Core business objects that represent the fundamental concepts of your application
2. Use Cases: Single-responsibility classes that implement specific business operations
3. Repository Interfaces: Abstract definitions of data operations that the domain layer needs
4. Value Objects: Immutable objects that represent descriptive aspects of the domain

The domain layer doesn’t depend on any external frameworks or libraries, making it highly testable and maintainable. It defines the contract that other layers must follow, rather than depending on them. This independence allows you to change the implementation details of the data or presentation layers without affecting the core business logic.

Presentation Layer

The presentation layer is responsible for the user interface and user interaction. It includes:

• UI Components: Activities, Fragments, Composables, or other UI elements
• ViewModels: Manage UI state and handle user actions
• State Models: Immutable objects that represent the current UI state
• UI Events: User interactions that trigger business logic

In the presentation layer, UI components observe state changes from the ViewModel and update accordingly. It’s a bad practice to expose data directly from the ViewModel to the UI layer. Instead, you should use a single State Model that contains only the data needed for UI rendering.

The key benefit of this approach is that the UI can focus solely on displaying data, not on data transformation or business logic. The UI should never modify state directly unless it’s the sole source of that data. Only the owner of the data (typically the ViewModel) should be allowed to update it.

This principle of immutability and controlled data flow helps prevent bugs, makes the code more testable, and ensures a predictable UI state. The presentation layer depends on the domain layer, not vice versa, maintaining the dependency rule of Clean Architecture.

Thank You!