do you think this module structure is normal or ar...
# gradle
l
do you think this module structure is normal or are there better options?
t
I personally prefer package-by-feature
j
They are modules, not packages
IMO domain should be a Kotlin module
l
@Javier domain is a Kotlin module. or do you mean that it is not an android module?
j
domain is a kotlin module? in that photo it looks like a android module
can you expand it?
l
@Javier Do I need to remove plugins related to android?
t
what use is having domain as a standalone module?
j
Yeah, domain should be agnostic to framework
l
@tddmonkey at least for testing
j
So having it as Android module force you to avoid Android API usages and it build faster
t
What’s in there?
l
@Javier maybe it is worth using a multi-platform architecture in general?
j
IMO yes
l
@tddmonkey I store use cases and gateways there
j
If your domain module is
common
, it means you can use it in Android or iOS, so agnostic to the framework
l
@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
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
understood, in this case, I will have to slightly redo the project structure
@Javier what can be used instead of
kotlin("android")
plugin?
j
You have kotlin jvm modules already, detekt maybe?
"org.jetbrains.kotlin.jvm"
or
kotlin("jvm")
l
thanks
@Javier What structure do you think is more correct? - common - - core - - domain - - source - - - remote - - - local or - common - - core - - domain - source - - remote - - local
j
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
I have often observed this structure: - platform1(android) - platform2(ios) - common - - domain - - etc is it necessary to place all modules inside the common?
j
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
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
common is just a folder
message has been deleted
here common is a folder no?
l
yes, it just folder
j
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
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.