I understand that Philipp has its own opinions on this subject, but calling these approaches "fatal" is wrong. They are not even mistakes. Whether you choose data modules, common modules, feature modules or hybrid depends on the project, period! e.g MVP, AB-Testing, hardening, libs, integrations, sdks may have different requirements and modularization patterns are changing along with development. Generally, you should to aim for low coupling and high cohesion, with some trade-offs. Anyone working on modularization of a large App module architecture with Dagger2 or Hilt knows how hard it can be. Cyclic dependency errors, missing bindings, moving assets, dependencies, sub-module to App communication problems are common. It is true, that modularization from day one takes more time, but this is nothing comparing to modularization of a monolithic application. Deciding when is the best time to start modularizing and explaining why you need to add this refactors to sprint planning are not easy as well. If you use mediator modules, common modules and feature modules wisely, right from the beginning, it will pay off.

Thanks for such a comprehensive answer to multi-module approach, cause in most of articles I've faced, modularization by layers everywhere is positioned as a just alternative to modularization by features, and I have the same concerns about modularization by layers, that you just described in video. Very cool!

Thanks for the great content! I didn't use modularization yet, but i will definitively be looking for or even creating CLI tools to help me build the modules if it takes that much time. I understand that early modularization can be bad, but "costing a lot of time" to setup the modules shouldn't be the reason, and if it is then we need a tool to fix this situation, the best way to handle wasted time to do "setup stuff" is investing even MORE time to build tools to automate the boring parts, because you only write it once and it helps in every other project. In the end it is just boilerplate code for Gradle to be happy and the modules work properly. Other technology stacks already have the tools necessary so that the developers don't need to manipulate code to create/attach a module as a dependency. But as I said, i didn't work with modularization yet, maybe such tools are not trivial to create in the Android&Gradle ecosystem (for such a mature tool like Gradle it shouldn't be a challenge though).

Thank you for such a useful video bro! You made my day as usual✊🏻😊😉

Great video Philipp. Thank u. But what about the common use cases or data classes?

Surely modularisation requires some work and may not always be worth the hassle. However, extracting a platform-independent business logic SDK into a separate module so that it is isolated from the application's platform-specific code somehow still sounds like a good idea to me for very many projects.

Hi Philipp, nice course btw. In your course only the tracker module uses room and I'm curious to know how you handle singletons like Room database and retrofit which are expensive to create with this approach

one must have to deal with the layer-based modularization when it comes to Kotlin multiplatform. otherwise yes i totally agree with you on the drawbacks of such strategy :) good video

Great video, and very informative as always! You explain very well so I have a video request/ a topic that does not have a lot of information available. Would you consider doing a video about firebase authentication and firebase registration of users using jetpack compose ? Would be awesome if you could! Anyway, keep those videos coming :D

I wouldn't say that dividing application into data, domain, presentation etc. is wrong. For example one person can work on data, domain and another on presentation module. The only place where the modules meet is interface. Modules are good for dividing the work in team and avoiding merge conflicts. How often did you reused module any way ?

great video brother. please make a video on a simple API call with multi-module. please, please...

it would be great if you could make a tutorial to use kotlin DLS, set up ... kts like in the video above.

Please make a video on how to implement stripe payment in the app.

Hi @Phillip, one Question... Looks like "Onboarding" module was created as "New Module" (Phone & Tablet), but the inner "modules" were created as "Android Libaries" , is that correct ?, if it so, why "core" is created as library ? Thanks!

once I modularize the app, how can i have a team work on one module while not exposing the rest of the app using a VCS (ie:git)?

Hey Philip, how would you do top level navigation then with this feature based modularization? Eg moving from onboarding to home screen. Keep in mind the onboarding screen shouldn't know what activity it opens after it's done.

How about sharing some useCases or dataSources between features , should we duplicate them?? 🧐

thanks for sharing great knowledge sir. sir i created an app for multiple people from the same source with different name, themes, server and google's .json configuration file. the problem is when i update one i need to update others too. is there a why to create multiple apps from the same source with different name, themes, server and google's .json configuration file from one project with different source sets. thanks.

Hey, Philipp, thank you for the video. It’s always fun and useful to look at some ideas from your perspective. Keep it up.

Your approche makes sens to me a-lot .

Hello Philipp, interesting video ! I have been using for years a layer-base multi-module architecture and I'm happy with it. This feature-base management sounds interesting. I will give it a try. One question though. As said in your video, you structure each module by layer. Does it mean you create a dedicated retrofit instance for each data layer ? What about Room instance and di directory ? Thanks in advance;

When you have many feature based modules, to setup a CI\CD process for this would be a hell I guess ?

I think you have missed a thing, if we don't create modules based on layers, how can we expose only domain layer?

Phillip, do we need a domain layer .. if I have sdk style library modules. I went to droidcon .. 2018 .. when they said it's useless to create Domain abstraction in a multi modular architecture..

very cool video

TBH I am not a big fan of having the core modules, because, in the end, this will become a kinda god module. All the features modules will be dependent on this module. And change any change in the core module would frequently happen because everyone will put all commons methods utility functions will lead to recompilation of this core module and because of the dependency graph of modules with core can't achieve the parallelism until this god module gets compiled.

Slow builds alert: move all kapt to separate leaf-module. It will make your builds much faster as they won't compile if you do not change them

Hello

Yeah, modulatization helps to build projects faster. But if your project has 300+ modules, it won't work. Because the configuration will take more time. The Gradle team seems aware of this issue, but I don't know if they are working on it

I would instead recommend having a top level "domain" container module that contains various submodules parts of your domain("domain:a", "domain:b"), and a top level "data" container module that contains various types of data modules associated with your domain ("data:a1", "data:a2", "data:b1", etc.). And finally a third presentation or feature module container that contains your various features modules. The feature based structure here assumes that your domain is tied to a specific feature, which is not always correct. For example, think about a "user" domain (and associated object / use cases) containing information about your "user" account. You would want to reuse that "user" domain object (and underlying data layer) across multiple features, perhaps in the user account page (where you display the full user details and where they can edit them) or in some home page where you welcome the "user" by their first / last name and wish them a happy birthday once a year (using their DoB). In all likelihood this would be coming from a single user domain object (cached). Your domain and the associated use cases is potentially going to be reused across multiple features / screens (as it should be), and so shouldn't be tied to a specific screen or feature. The package structure presented here (although it works) would suggest to other developers working on the project that presentation / domain / data are one and the same. If you reverse that package structure (domain at the top) then you will start seeing your screens / features as just ways to display and assemble multiple domain objects together via a view model or similar (almost like architectural composition).

WRONG! We always start all our projects with multi-module and we benefit from it everyday going forward. YES ... by feature is correct but have never seen anyone do it any other way.

I agree that these are good generic advices but I don’t think it’s the best for all cases. At work we knowingly (as in, we knew the its drawbacks) chose a “pres domain data like” (not exactly) module structure because it achieved what we wanted without complicating the project with one module per feature which in our case had no benefits. So in the end, nothing is wrong.. in a given context, something can be correct which would be wrong in other contexts. Just wanted to add my thoughts 😁 But it’s a good video as always 👌

Would be interesting to know how this contrasts with Google-recommended approach to modularize by both, layer and feature.. (ukposts.info/have/v-deo/aWaEq4qtsXqAkXU.html)

multimodule is overrated. if you can replace module with kotlin package - you don't need module.

I'm sorry I don't have time to write a better comment but honestly very mediocre video. Allot of the information in the video is lacking and some things is just not fully correct.

Oh dear. This is garbage. 1) His advice is wrong. period. 2) He doesn't understand the need for separation of concerns. To quote one of the founders of UML , "It is to localize change" - think about it Philipp.

Hi Philipp, thanks for the video. In my case I have in my personal application also modularized the project, but a friend when trying to clone the project one of the modules fails to compile, the module remains with the blue square icon, instead of the 3 colored bars, when trying to run the project returns this error: Could not resolve project :common. Required by: project :app project :app > project :football project :app > project :adobeclippers > No matching configuration of project :common was found. The consumer was configured to find an API of a component, preferably optimized for Android, as well as attribute 'com.android.build.api.attributes.BuildTypeAttr' with value 'debug', attribute 'com.android.build.api.attributes.ProductFlavor:environment' with value 'footballApp', attribute 'com.android.build.api.attributes.AgpVersionAttr' with value '7.4.0', attribute 'org.jetbrains.kotlin.platform.type' with value 'androidJvm' but: - None of the consumable configurations have attributes. If you could give me a hand in case something like this has ever happened to you? In the settings.gradle all the modules appear correctly. include ':app' include ':common' include ':styles' include ':repositories' include ':player' include ':football' include ':analytics' include ':adobeclippers'

Ich dachte build Tools mit generate *.iml würde meine build Zeit beschleunigen 😜