do you think this module structure is normal or ar...

# gradle

[Loboda Deni]

do you think this module structure is normal or are there better options?

[tddmonkey]

I personally prefer package-by-feature

[tddmonkey]

http://www.javapractices.com/topic/TopicAction.do?Id=205

[Javier]

They are modules, not packages

[Javier]

IMO domain should be a Kotlin module

[Loboda Deni]

@Javier domain is a Kotlin module. or do you mean that it is not an android module?

[Javier]

domain is a kotlin module? in that photo it looks like a android module

[Javier]

can you expand it?

[Loboda Deni]

@Javier Do I need to remove plugins related to android?

Untitled

[tddmonkey]

what use is having domain as a standalone module?

[Javier]

Yeah, domain should be agnostic to framework

[Loboda Deni]

@tddmonkey at least for testing

[Javier]

So having it as Android module force you to avoid Android API usages and it build faster

[tddmonkey]

What’s in there?

[Loboda Deni]

@Javier maybe it is worth using a multi-platform architecture in general?

[Javier]

IMO yes

[Loboda Deni]

@tddmonkey I store use cases and gateways there

[Javier]

If your domain module is common, it means you can use it in Android or iOS, so agnostic to the framework

[Loboda Deni]

@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?

[Javier]

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

[Javier]

you can keep it as kotlin jvm module btw

[Loboda Deni]

understood, in this case, I will have to slightly redo the project structure

[Loboda Deni]

@Javier what can be used instead of kotlin("android") plugin?

[Javier]

You have kotlin jvm modules already, detekt maybe?

[Javier]

"org.jetbrains.kotlin.jvm" or kotlin("jvm")

[Loboda Deni]

thanks

[Loboda Deni]

@Javier What structure do you think is more correct?

- common
- - core
- - domain
- - source
- - - remote
- - - local

or

- common
- - core
- - domain
- source
- - remote
- - local

[Javier]

I think if all is common it has no sense to exist directly

[Javier]

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

[Javier]

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)

[Loboda Deni]

I have often observed this structure:
- platform1(android)
- platform2(ios)
- common
- - domain
- - etc

is it necessary to place all modules inside the common?

[Javier]

you can use multiplatform modules in other modules

[Javier]

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

[Loboda Deni]

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?

[Javier]

common is just a folder

[Javier]

message has been deleted

[Javier]

here common is a folder no?

[Loboda Deni]

yes, it just folder

[Javier]

domain will have the next structure

[Javier]

domain
• commonMain
• androidMain
• jvmMain
• etc (iOS, tests, etc)

[Javier]

but this domain can be placed in the folder you want

[Loboda Deni]

but should modules be grouped into this folder(common)? or can I leave them at the root? what is the right thing to do?

[Loboda Deni]

I think in the context of multi-platform architecture it is better to group the modules inside the common folder.