Part 3 of 5

The idea of ​​the KMM project is to be able to reuse as much code as possible. The business logic doesn’t vary by platform, it’s always the same, so it makes sense that our domain layer (which would be pure Kotlin) is in a shared module of the project.

This layer is one that can be reused by any platform, be it web, mobile or terminal. This is where we define the contracts or interfaces of our repositories and use cases or interactors. For the current example, we only have one interactor: GetMoviesInteractorwhich, as its name suggests, will handle receiving the movies and will depend on MovieRepository Repository which will be an interface in our domainthe packet.

class GetMoviesInteractorImpl(private val repo: MovieRepository) {
override suspend fun execute(): List {
return repo.getMovies()
}
}

As you can imagine, all the classes and functions inside the domain have no dependency on any external platform framework (be it iOS, Android, etc.). It depends only on itself and its definitions. Our GetMoviesInteractor expects any object in its constructor that implements MovieRepository Interface and returns objects belonging to the same layer.

You might be wondering what is the point of a use case that does nothing but call a simple repository function? It doesn’t make much sense at first glance (and in many cases, especially in small apps, it doesn’t), but the use of interactors Can simplify the creation and maintenance of business logic.

suppose, our Movie inside the model is a directorDetail the type of attribute MovieDirector(second class). Film stores do not necessarily contain director information, and it may be necessary to consult another repository for information.

class GetMoviesInteractorImpl(
private val moviesRepo: MovieRepository,
private val directorsRepo: MovieDirectorRepository,
private val productionCompanyRepository: ProductionCompanyRepository
) {
override suspend fun execute(): List {
val movies = moviesRepo.getAll()
val moviesDetail = movies.map { movie ->
MovieDetail(
movie = movie,
director = directorsRepo.getDirectorDetailById(movie.directorId),
productionCompany = productionCompanyRepository.getCompanyDetailById(movie.productionCompanyId)
) 
}
return moviesDetail
}
}

In the end, our shared The module (where we have all the shared cores of our application), is structured as follows:

• – androidMain: Here we add a database driver factory Which is a SqlDelight implementation for Android.
• –iosMain: Same as above, here we implement the example of SqlDelight database for iOS.
• – commonMain: here it is Multiplatform Magic, there will be divisions for us inside domainAnd data layers. Ours is in the domain package interactorThe Movie Model, and repository interface. In the image, you can see a DispatcherProvider.kt which contains the definitions of dispatchers of Kotlin coroutines to be used in the implementation of repositories or data sources within the data layer.

It is worth clarifying that in androidMain And iosMain packages, you’ll find Kotlin code for those platforms, such as the SQLight database manager. The code for the business/domain layer is found at commonMain Because it is the most reusable and free.

We will see how the data layer is structured in the next post. Meanwhile, it should be clear that the domain layer (which we implemented in the domain package) shared/commonMain module), is the one that will be reused by both the platform and the data layer, so its implementation is abandoned androidMain And iosMain,

One more important detail: don’t forget to add kotlin coroutines dependency in our shared Modulus.

// shared/build.gradle.kts
sourceSets {
val coroutineVersion = "1.6.0-native-mt"
val commonMain by getting {
dependencies {
implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:$coroutineVersion") {
version { strictly(coroutineVersion) }
}
}
}        ...    }

You can follow the project’s progress on GitHub:

This is the second post in which we have talked about the domain layer. In the following, we will talk about the data layer. This guide is divided into the following posts:

1. introduction
2. solution design
3. create domain layer (this post)
4. create layer data
5. Implementing Presentation Layer