About 11 months ago, I created a demo project in Kotlin Multiplatform. To be honest, I had a lot of difficulties getting it to work with iOS. There were a lot of bugs in the compiler and I had to write some workarounds. Since then I haven’t touched that project again and I haven’t made any (public) apps using Kotlin Cross-Platform either.
With the recent update to the Android Architecture Guide, I noticed that several doubts came up on how to respect the already well-known “Clean Architecture”. Or what is the best way to structure your project. And the answer is quite short: it depends.
So we are going to review some concepts and recommendations to have a clearer idea of which design option you should go for.
This post, specifically, will try to explain the architecture of layers through a Kotlin Multiplatform project, where the need to have a “section” dedicated to business or domain logic will be evident.
Understanding the magnitude of the project
When making architectural design decisions, it’s important to consider various factors such as project complexity, functionalities, team size, available technologies, and scalability projections.
The requirements for a simple app developed by a small team of 3 people will differ from those of a robust point-of-sale system where 50 developers are actively modifying the code on a daily basis.
For the former, a monolithic project that separates the data access and graphical user interface components might be sufficient.
However, in the latter case, it becomes necessary to create modules for each functionality, with each team taking ownership of a module. It’s important to establish a consistent structure across all modules to ensure coherence and maintainability.
When designing an architecture for your application, the recommendation will always be to respect a basic principle of software development that escapes any technology or framework: The separation of responsibilities or Separation of Concerns.
It’s crucial to have a clear understanding of the SOLID principles when designing software architecture. These principles guide the separation of responsibilities within your codebase, even in small projects. For instance, if your app’s sole purpose is to display a list of movies from a single data source, a complex design may not be necessary.
However, it is still important to differentiate the code responsible for displaying the data (UI) from the code responsible for fetching the movies. In this regard, the Google team made the domain layer, which handles the business logic, optional. For more insights on this topic, you can check out a Twitter conversation I had:
Domain layer for business logic: repository interfaces, business models, use cases and interactors
— Jose Flavio (@jflavio11) December 21, 2021
Data layer for accessing to data sources, there are repository implementations that depends on different data sources (room, rest apis, files, shared prefs, etc)
Layered Architecture or Clean Architecture?
Over the past few years, the Android developer community has made significant progress in improving knowledge and best practices for app architecture design. Concepts like SOLID principles, design patterns, and the implementation of “Clean Architecture” have gained popularity.
During candidate interviews, it is common for individuals to claim familiarity with SOLID principles or having “used” Clean Architecture. However, they often struggle to provide clear explanations or examples of how they have applied these concepts or made design decisions.
It is even often said that “Clean Architecture” is architecture itself. I do not share this statement. A quick review of the 2012 book or article “The Clean Architecture”, we can see that what Uncle Bob calls “clean architecture” is an idea that mixes various architectural designs.
In the end, the main goal of the clean architecture is to uphold the principle of Separation of Responsibilities by dividing the code into layers. From my perspective, the clean architecture represents a more focused and precise approach to layered architecture.
By the way, I’m genuinely interested in hearing your viewpoint on this topic. Architectural discussions are always fascinating!
Note: I’m currently working on an open-source Kotlin Multiplatform project on GitHub as well. Feel free to check it out!
Github - jflavio11/LayeredKotlinMultiplatform
Example of Mobile Kotlin Multiplatform app for showing about layered architecture
github.com
What’s Next
This has been the first post in which I have made a brief introduction to the objective. In the following, we will design the solution and implement it by creating a Kotlin Multiplatform project. This guide will be divided into the following posts:
- Introduction (this post)
- Designing the solution
- Creating the domain layer
- Creating the layer data
- Implementing the presentation layer