By layer or feature? Why not both?! Guide to Android app modularization

In this talk, we will give you a set of common patterns and recipes for modularizing your project in the context of the modern Android app architecture. Learn the types of modules and their role in a multi-module codebase.
Resources:
Guide to Android app modularization → goo.gle/3NM5KLr
Speaker: Miłosz Moczkowski
Watch more:
Watch all the Android Dev Summit sessions → goo.gle/ADS-All
Watch all the Modern Android Development track sessions → goo.gle/ADS-MAD
Subscribe to Android Developers → goo.gle/AndroidDevs
#Featured #AndroidDevSummit #Android

[@sawyermade5469]

This is perfect, explains everything concisely while simultaneously being terse. Cheers.

[@walrider7374]

I mean, it explains the theory, but how do you achieve multi module layer in real world??

[@sawyermade5469]

@@walrider7374 I mean, you'd have to design a feature level architecture where each feature is a module, right?

[@walrider7374]

@@sawyermade5469 oh, so for example authentication module having clean architecture in it? source, repository and usecase package? and the same for all the other feature modules?

[@sawyermade5469]

@@walrider7374 In my case, I have login as a module, then I have a data module which has all my API stuff (ktor), DataStore, models, and Firebase etc. Then I have a home screen module, job management module, etc where each module after login and data is only coupled with login and data, there's no coupling between the rest of the features. Im also working on a consistent UI that I will probably put in each individual module once I get there. Theres some redundant code but I can work on the features individually without breaking anything else.

[@seguramlk]

​@@walrider7374Actually according to this approach, you'll have at least 3 modules. Let's say for example: user:ui, user:domain and user: datasource You'll also need to have 3 common modules: ui, domain and datasource Your feature modules will depend on their parents. So user:ui will depend on ui, user:domain will depend on domain and so on So from a top-down view, you'll have this setup: user:ui ⬇️ user:domain ⬇️ user:datasource You'll create packages like this: datasource⤵️ datasource(module) user:datasource The root datasource package will be a simple folder Inside of it you'll have 2 GRADLE Modules :datasource (Base module, common to all other modules) :user:datasource (This is your specific feature module, in this case, the feature is called user, hence the name. It's important to apply meaningful names to your modules so you'll look at it and will already know what it does) Hope I could help you man If you have any other ideas, leave them here. I don't know everything, far from it actually, so it's always great to see different approaches 👍

[@chuyebrian8949]

Nice explanation.

[@guilhermenunes3130]

great overview :)

[@davetao]

In a large codebase, additions to a feature data module cascades into changes to changes to other modules as well and in effect causes teams to block each other

[@SHURA_RC]

Estoy entrando en este tema y quedo muy bien explicado.

[@victormartinezlegaz1871]

In my experience, when scaling to a large number of developers is better to avoid sharing business logic and data between feature modules. This may involve some duplication, but it can help prevent coupling and simplify maintenance in the long term.

[@seguramlk]

@victormartinezlegaz1871 Hey Victor. How would you achieve that? Could provide some examples on how to do that or any real world scenarios where you struggled with this approach. I'm curious to know more about it. Thanks for sharing 👍

[@marlonlom]

How can i use firebase auth or firestore in separated modules instead of the app module ??

[@GoDigital685]

🤩🤩🤩🤩

[@vipinsahu1306]

Separate codebase by Feature module ending up with Clean Architecture

[@koenkraak5922]

I really don't see how the combined architecture solves the redundancy/code duplication problem. The domain:books still has no access to authors (Even though it can access the data:authors, it cannot obtain them with use cases/ re-used business logic) and suddenly the ui layer uses both domains? Does that mean that the GetBooksWithAuthorUseCase is implemented in the ui layer now? Really confusing

[@GakisStylianos]

GetBooksWithAuthorUseCase can be in a module which can see both the other two domain modules. No need for it to be implemented in the UI module of course.

[@kalidsherefuddin]

Ok

[@d_chem_]

Are you sure that the domain module depends on the data module?

[@peterfischer2748]

This seems to be the official decision by Google in their MAD series. The domain module there only consists of use cases rather than domain models. Since this diverges from common definitions (like DDD and clean architecture) I'm sure Google discussed this internally. I'd love to hear their thoughts and pros and cons of the different approaches. Maybe they consider this approach more beginner friendly because it avoids IoC.

[@gregoryphiri5724]

Was actually thinking the same like using DIP to have public interfaces for the data layer in the domain n have the data sources in the data modules implementing the interfaces in the domain.

[@BigCarso]

@@peterfischer2748 I don't think it necessarily avoids IOC, but I think it is just a more sensible description of the relationship between domain and data. Using an interface IMO doesn't mean you can say domain doesn't depend on data layer. It still calls functions that direct to the data layer

[@seguramlk]

I think it makes sense when you modularize by both Feature and modules because you'll have specific feature modules inside common modules such as datasource or domain. In this case, you can either have an interface to communicate with lower modules but in this approach you'll have to depend on specific feature modules for example: user:ui DEPENDS ON user:domain THAT DEPENDS ON user: datasource that only depends on its parent :datasource Your parent :domain module should not depend on :datasource though. Only its children should depend on :datasource children and on :datasource by association

[@mohammedabdelsabour1412]

Data module depend on domain module not reverse I sure

[@BigCarso]

It depends what you mean by depends on. IMO IOC doesn't mean "the data layer depends on domain module"

[@seguramlk]

I don't think so. I don't see any problem with the domain module depending on the datasource module. The domain module needs to process data, business logic. So it needs to have Access to repositories and other files in order to inject them into Usecases so they will be able to process that data and provide it to the UI layer Maybe it's not the best approach, but it sure is better than having no organization in your projects whatsoever The worst case scenario is that if you need to change this arch setup, it will be easier than migrating from messy projects in regards to modularization

[@coldwised]

bruh, none of your repositories follow this architecture

[@seguramlk]

Do as I say but not as I do. I like this approach though

[@3CHONPRODUCTIONS]

This was so poorly explained and I bet when the example comes out it will never compile just like all their other repos