Arquitectura por capas para KMP

As your KMP app grows, shared code can turn into a tangle. A clear layered architecture keeps every piece in its lane so both apps stay easy to change.

Most KMP apps settle on three layers: data, domain and presentation. Each has one job, and dependencies flow in a single, predictable direction.

The data layer talks to the outside world: Ktor for HTTP, SQLDelight for storage. It fetches raw bytes and hands clean data upward, hiding the details.

The domain layer holds your business rules and models. It knows nothing about HTTP or SQL, so it stays pure, portable and trivially testable.

The presentation layer prepares state for the screen. Shared ViewModels live here, turning domain data into the StateFlow each UI collects.

The golden rule: outer layers depend on inner ones, never the reverse. Presentation knows domain; domain knows nothing about either neighbour.

Layers connect through interfaces, not concrete classes. Domain declares what it needs; data provides the implementation, so you can swap pieces freely.

Each layer can own its shapes: a network DTO in data, a clean model in domain. Mapping between them keeps API quirks from leaking into your rules.

Separation pays off when requirements shift. Swap a REST API for GraphQL and only the data layer changes; domain and presentation never notice.

Data, domain and presentation can all sit in commonMain. Both Android and iOS reuse the entire stack and only supply the final native screen.

You do not need ten layers on day one. Begin with these three, keep the dependency arrows clean, and let the structure grow only when it earns its keep. 🙂

Which way should dependencies flow between layers?

You split shared code into data, domain and presentation, pointed dependencies inward, and connected layers through interfaces. Clean lanes, easy changes. 🎉