When you modularize, and you need some shared code in each feature module

We actually don't seperate code per feature module, but per type: domain module, repositories module, datasources module, viewmodels module

Well thats different, btw imo I dont think that scales and is incorrect

@Orhan Tozan that sounds really awful to work with

Well, you can't do multiplatform single feature modules

and theyre wrong, your not gaing much, sure you need shared modules, but imagine twitter & periscope, you cannot just share "domain" because it contains twitter specific etc

They can, imagine a server-client setup. The server and client use the same domain.

sure, but if youll have something client specific, then youre screwed

Client is not screwed, if client has specific models, he will use that as is own layer on top of the domain layer. composition indeed

then its not what you described, or I undestood but okay

Modularizing by layer is an anti-patterm that everyone else moved past 10 years ago, except for Android developers who still cling to it. If your app and consequently the team that works on it gets large enough then you need to split the large team into independent smaller teams or the organizational overhead will kill you. You can split either by technology (what people used to do) or by domain area. If you split by technology then every feature that has to be developed needs to be communicated across many team boundaries: frontend, Backend, mobile, UX, ops. Once again, you will drown in overhead. Which is why everyone has adopted the domain-driven way of vertically integrated teams. The code base has to reflect the organizational structure to enable independent teams, which means vertically integrated feature modules.

I think you are talking about a different thing

Are you modularising out principle or do you have empirical data that says its it best way to go for the application?

@dewildte not really, same as any cross module communication, just put it on common module (or root/base and fck it)