Search⌘ K
AI Features
Home
Courses
Grokking the Mobile System Design Interview

Architectural Principles and Layered Design

Explore core mobile architectural principles such as DRY, SOLID, and separation of concerns, and understand how layered design structures UI, domain, and data layers. This lesson helps you organize code for scalability, maintainability, and easier team collaboration in evolving mobile apps.

We'll cover the following...

Every mobile app begins with good intentions: a clean folder structure, a few screens, and code that feels easy to navigate. But as features multiply, teams grow, and deadlines tighten, that clarity begins to fade. Files expand. Logic spreads unpredictably. One change breaks three things. Suddenly, a once-simple app feels fragile, and no one is sure why. The reason the app isn’t working well is the lack of a proper structure. It has nothing to do with the quality of the code itself.

Mobile architecture is about defining clear boundaries, organizing responsibility, and creating a system that can absorb change without collapsing.

This chapter explores architecture patterns that help us tame complexity as mobile apps evolve. We’ll also explore the structural decisions that make codebases maintainable, adaptable, and resilient overtime. This chapter will cover the following:

At its core, mobile architecture exists to solve the recurring challenges mentioned below.

  • Platform fragmentation: iOS and Android follow distinct life cycle models and UI paradigms, requiring developers to account for platform-specific behavior and design conventions.

  • Frequent UI changes: User interface designs evolve rapidly, often leaving limited time for architectural refactoring or deep technical alignment.

  • Resource constraints: Mobile devices operate under strict limitations in memory, processing power, and battery life, necessitating efficient and optimized code.

  • Expanding codebase complexity: Continuous feature development, bug and quick fixes contribute to a growing and increasingly complex codebase overtime.

This brings us to the first architectural tool in our toolbox: architectural principles and layered design. It lays the groundwork for everything that follows: by separating responsibilities into distinct layers and enforcing design boundaries, we gain flexibility, clarity, and control.

With this context in mind, we now move into the principles that bring structure and discipline to architecture, starting with DRY, separation of concerns, and the SOLID rulebook.

Mobile architecture principles

A well-structured mobile system is the result of applying time-tested principles that bring clarity, reduce risk, and create a foundation for long-term success. These principles are not tied to any specific language or platform; they shape how developers think, organize, and evolve systems. This section presents the most influential architectural principles and how they bring order to mobile app development. Principles like DRY, separation of concerns, and SOLID are practical tools to tame complexity.

DRY principle

The DRY (don’t repeat yourself) principle encourages a single, unambiguous representation of every piece of knowledge in a system. Duplication may appear harmless at first, but overtime, it increases the cost of change and the likelihood of inconsistency.

In mobile development, violations of DRY often occur when validation rules, data transformations, or network logic are copied across multiple screens. Centralizing this logic not only simplifies future updates, but also improves test coverage.

Before refactoring (duplicated logic):

Kotlin
// In screen A
if (email.contains("@") && email.length > 5) {...}
// In screen B
if (email.contains("@") && email.length > 5) {...}

After applying DRY:

Kotlin
fun isValidEmail(email: String): Boolean = ...

The one subtle way developers violate DRY in mobile apps is by copying, and slightly modifying UI logic between screens instead of extracting shared components.

Typical areas to apply DRY in a mobile application include:

  • Input validation.

  • Network response mapping.

  • Constant definitions.

  • Date or string formatting logic.

Separation of concerns principle

This principle is foundational to layered design. It ensures that each part of our app handles a distinct responsibility, no more, no less. When concerns are mixed, testing becomes harder, and changes in one place ripple across the app. It improves readability, facilitates testing, and enables teams to evolve features independently.

In a mobile system, separation of concerns creates a clear boundary between how data is presented, how business rules operate, and how data is fetched or stored, as given below:

The separation of concerns in mobile system
The separation of concerns in mobile system

A change in the data source or format (say, from REST to GraphQL) affects only the data layer. The UI remains untouched, and domain logic continues to behave as expected.

SOLID principle

The SOLIDSingle Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion. principles represent five core ideas that guide the design of flexible and maintainable object-oriented systems. These principles are particularly valuable in complex or evolving mobile applications. Let’s explore each through a mobile lens:

Principle

Guiding Idea

Simplified Mobile Example

Single responsibility

Each class or component handles one specific task

A class that saves user settings should not also update the screen or send logs

Open/closed

Systems support adding new behavior without changing existing code

You can add a new type of notification without editing the existing alert logic

Liskov substitution

Replacements (subclasses) should behave as expected when swapped in

Switching from offline to online data source should not break how the app works

Interface segregation

Components should only be asked to do what they need to do

A settings screen only asks for user preferences, not unrelated account details

Dependency inversion

High-level logic depends on general rules, not specific details

A feature works with any image loader as long as it follows a defined interface

Note: SOLID is used by teams behind Android Jetpack libraries to design APIs that evolve without breaking existing apps. It’s why Room, Navigation, and WorkManager stay consistent across versions.

These principles encourage modular thinking, and help teams build systems where components are interchangeable and behavior is predictable.

Problem: Our current ProfileActivity fetches user data, parses the JSON, applies business rules, and displays the UI, all in one class.

Solution: Refactor the path using the following principles.

  • Single responsibility: Move parsing to a separate model transformer.

  • Separation of concerns: Delegate API fetching to a repository.

  • Dependency inversion: Make the repository an interface injected into the activity.

  • DRY: Extract shared user formatting logic into a utility class.

As a result, our ProfileActivity focuses purely on rendering. All else is testable in isolation.

This structure reflects DRY, separation of concerns, and all five SOLID principles. Each class has one role, dependencies are abstracted, and changes remain localized.

Strong principles lead to strong architecture. In the next section, we translate these principles into concrete architectural layers: UI, domain, and data, and explore how to design mobile systems that are both scalable and coherent.

Layered architecture in mobile

Every growing mobile app eventually asks one question: Where does this logic belong? Layered architecture answers that question with clarity. It provides a structured way to group responsibilities into logical boundaries, ensuring each layer is responsible for the tasks under its boundary. This structure is not just about aesthetics; it’s about control, collaboration, and scalability. Each layer in a mobile architecture operates with a well-defined purpose.

  • UI layer: This layer is the interface between the user and the application. It should not include business rules, data parsing, or network logic. The responsibilities may include:

    • Display data using activities, fragments, composables, or SwiftUI views.

    • Handle navigation and UI events (button clicks, gestures).

    • React to states provided by other layers (layers with business logic) or presenters.

Kotlin
userViewModel.userState.observe(viewLifecycleOwner) { state ->
    when (state) {
        is Success -> showUser(state.data)
        is Error -> showError()
        is Loading -> showLoading()
    }
}

The UI layer relies on state, not behavior. It observes, displays, and delegates.

  • Domain layer: This layer is the most isolated and platform-independent part of the architecture. It holds the rules, policies, and business decisions of the application. Unlike other layers, it does not know whether the data comes from a local database or a remote server. The responsibilities are mentioned below.

    • Encapsulating business logic in use cases or interactors.

    • Defining domain models.

    • Coordinating flows and outcomes between UI and data layers.

Kotlin
class FetchUserUseCase(private val userRepository: UserRepository) {
    suspend fun execute(userId: String): User {
        return userRepository.getUserById(userId)
    }
}

The domain layer acts as a firewall between volatile external data and the stable inner logic of the system.

  • Data layer: This layer is responsible for providing the domain layer with data. It orchestrates between network APIs, local databases, shared preferences, or any other source of truth. It abstracts away the implementation details behind interfaces, as it:

    • Fetches, stores, and caches data.

    • Maps raw data into domain models.

    • Handles errors and connectivity gracefully.

Kotlin
class UserRepositoryImpl(
    private val apiService: ApiService,
    private val userDao: UserDao
) : UserRepository {
    override suspend fun getUserById(id: String): User {
        val response = apiService.fetchUser(id)
        return response.toDomainModel()
    }
}

The data layer exposes clean interfaces to the domain, regardless of how or where the data is sourced.

An overview of layered architecture
An overview of layered architecture

Layered design is an architectural discipline. Its benefits span across engineering practices, team productivity, and future adaptability.

  • Testability: Each layer is testable in isolation without deep mocks or side effects.

  • Modularity: Features evolve independently with well-defined ownership.

  • Scalability: Teams work in parallel on layers without stepping on each other’s code.

  • Maintainability: UI and logic changes remain isolated, reducing regression risks.

  • Flexibility: Logic written in the domain layer can be reused across iOS, Android, and desktop.

With a clear understanding of architectural principles and the structure offered by layered design, the next step is learning how to apply these concepts in real development scenarios.

Architecture principles in practice

Knowing architectural principles and layered design is one thing; putting them into practice under real-world constraints is another. Mobile systems evolve under constant pressure: rapid releases, shifting requirements, and changing team structures. This section connects theory to practice, offering strategies to recognize common architectural pitfalls, enforce clean boundaries, and strike the right balance between flexibility and structure.

Architectural erosion happens subtly. Overtime, shortcuts and unclear ownership can result in tightly coupled systems. Recognizing violations early is key to preventing long-term debt. The common signs of breakdown:

  • UI screens contain network calls and parsing logic.

  • Business rules are copied across multiple screens.

  • One class handles both data access and user interaction.

  • Feature changes affect unrelated parts of the app.

For example, the following login screen handles API calls, session storage, and navigation. Each of these concerns belongs in a different layer:

Swift
// In a login screen
let response = apiClient.login(email, password)
if response.status == "OK" {
   userDefaults.set(response.token, forKey: "token")
   showHomeScreen()
}

By refactoring into separate layers, we can have the following separate code for each:

UI Layer
Domain Layer
Data layer
loginService.login(email, password) { success in
    if success {
        showHomeScreen()
    } else {
        showError()
    }
}

Creating structure is only the beginning. Maintaining it requires discipline and process support. Here are practical techniques to enforce boundaries across teams:

Technique

Purpose

Code reviews with a layer checklist

Ensure logic appears in the correct layer

Interfaces at boundaries

Prevent direct coupling between UI and data infrastructure

Naming conventions

Make responsibilities obvious at a glance

Project structure by layer

Physically separate UI, domain, and data logic

Unit tests per layer

Validate logic without relying on other layers

Note: Encourage teams to document where new logic belongs. If developers feel unsure where to place a class or method, the boundaries likely need clarification.

Overengineering can be just as harmful as under-structuring. For simple apps or early prototypes, a full domain layer might feel excessive. The key is to design for evolution, not just current simplicity.

For a prototype or an MVPMinimum viable product, we can combine the domain and data logic under feature modules. However, for a growing feature set, we should introduce a domain layer with a clear use case. On the other hand, large-scale apps must have fully separate layers with strict boundaries.

You’ve inherited a mobile codebase with features working as expected, but maintenance has become difficult. New team members struggle to locate responsibilities, UI logic mixes with data access, and feature duplication creeps in across modules. While rewriting from scratch isn’t an option, how would you improve the code architecture using mobile architectural principles?
Enter your answer in the widget below.

If you’re unsure how to do this, click the “Want to know the correct answer?” button.

Architectural Principles

Conclusion

Principles like DRY, SOLID, and separation of concerns provide guidance. Layers like UI, domain, and data give structure. Together, they turn chaotic code into systems that are easier to reason about, extend, and maintain.

In the next lesson, we explore mobile architecture patterns that sit on top of this layered foundation. Different patterns help organize logic within each layer, influence how data flows, and define the interaction between UI and business logic. Each pattern offers its own strengths, trade-offs, and ideal use cases.