https://kotlinlang.org logo
Title
l

Loboda Deni

07/31/2020, 8:30 AM
do you think this module structure is normal or are there better options?
t

tddmonkey

07/31/2020, 8:38 AM
I personally prefer package-by-feature
j

Javier

07/31/2020, 8:41 AM
They are modules, not packages
IMO domain should be a Kotlin module
l

Loboda Deni

07/31/2020, 8:42 AM
@Javier domain is a Kotlin module. or do you mean that it is not an android module?
j

Javier

07/31/2020, 8:43 AM
domain is a kotlin module? in that photo it looks like a android module
can you expand it?
l

Loboda Deni

07/31/2020, 8:44 AM
@Javier Do I need to remove plugins related to android?
t

tddmonkey

07/31/2020, 8:45 AM
what use is having domain as a standalone module?
j

Javier

07/31/2020, 8:45 AM
Yeah, domain should be agnostic to framework
l

Loboda Deni

07/31/2020, 8:46 AM
@tddmonkey at least for testing
j

Javier

07/31/2020, 8:46 AM
So having it as Android module force you to avoid Android API usages and it build faster
t

tddmonkey

07/31/2020, 8:46 AM
What’s in there?
l

Loboda Deni

07/31/2020, 8:47 AM
@Javier maybe it is worth using a multi-platform architecture in general?
j

Javier

07/31/2020, 8:48 AM
IMO yes
l

Loboda Deni

07/31/2020, 8:48 AM
@tddmonkey I store use cases and gateways there
j

Javier

07/31/2020, 8:49 AM
If your domain module is
common
, it means you can use it in Android or iOS, so agnostic to the framework
l

Loboda Deni

07/31/2020, 8:51 AM
@Javier I recently just discussed this issue, I was convinced that using a multi-platform architecture is an over complication, if the application is designed for only one platform. this is not true?
j

Javier

07/31/2020, 8:52 AM
Why should be over complication?, the only difference is you can't use Android things in domain, but you really should not be using Android things there
you can keep it as kotlin jvm module btw
l

Loboda Deni

07/31/2020, 8:53 AM
understood, in this case, I will have to slightly redo the project structure
@Javier what can be used instead of
kotlin("android")
plugin?
j

Javier

07/31/2020, 9:18 AM
You have kotlin jvm modules already, detekt maybe?
"org.jetbrains.kotlin.jvm"
or
kotlin("jvm")
l

Loboda Deni

07/31/2020, 9:29 AM
thanks
@Javier What structure do you think is more correct? - common - - core - - domain - - source - - - remote - - - local or - common - - core - - domain - source - - remote - - local
j

Javier

07/31/2020, 10:01 AM
I think if all is common it has no sense to exist directly
I use a mix structure which has data - domain - presentation data -> datasources modules domain -> usecases and repo interfaces modules presentation -> modularization based on features (user, userDetail, login, etc) plus common modules for shared sources like some views, models, etc
1
domain are kotlin modules, data depends (if it is a db, it is a android module, but for retrofit for example you can use a kotlin jvm module)
l

Loboda Deni

07/31/2020, 10:08 AM
I have often observed this structure: - platform1(android) - platform2(ios) - common - - domain - - etc is it necessary to place all modules inside the common?
j

Javier

07/31/2020, 10:19 AM
you can use multiplatform modules in other modules
For example, if you have a multiplatform module and an Android module implements it, you can use the common/jvm/android code in the Android module
l

Loboda Deni

07/31/2020, 10:21 AM
I understand. but is it possible to place, for example, the module
domain
in the root, and not in the
common
? or is it better not to do this?
j

Javier

07/31/2020, 10:22 AM
common is just a folder
here common is a folder no?
l

Loboda Deni

07/31/2020, 10:23 AM
yes, it just folder
j

Javier

07/31/2020, 10:23 AM
domain will have the next structure
domain • commonMain • androidMain • jvmMain • etc (iOS, tests, etc)
but this domain can be placed in the folder you want
l

Loboda Deni

07/31/2020, 10:25 AM
but should modules be grouped into this folder(common)? or can I leave them at the root? what is the right thing to do?
I think in the context of multi-platform architecture it is better to group the modules inside the
common
folder.