How to modularize the codebase

[lotdrops]

Sorry if this was discussed elsewhere, I didn't find it. Are we settled on modularization by layer?
UI needs to be separate from the rest because of KMP, that's for sure. However, I think we could split it by features instead of doing domain/data.
As I understand architecture, we want modules with high cohesion and with low coupling. If we split by layer I think we do not achieve those goals. Also, modularization by feature mimics how we'd split by "teams".
Also, I think it used to be common to modularize by layer but now I believe it is mostly done by feature. For example, it is shown in the android architecture page. Fernando Cejas made it popular, but then changed his mind about this because of feedback from the community.
I usually follow an approach similar to this. For small/medium apps I don't split features in api/impl, and my module-injector is inside of app.

Originally posted by @lotdrops in #68 (comment)

[lotdrops]

Sorry if this was discussed elsewhere, I didn't find it. Are we settled on modularization by layer? UI needs to be separate from the rest because of KMP, that's for sure. However, I think we could split it by features instead of doing domain/data. As I understand architecture, we want modules with high cohesion and with low coupling. If we split by layer I think we do not achieve those goals. Also, modularization by feature mimics how we'd split by "teams". Also, I think it used to be common to modularize by layer but now I believe it is mostly done by feature. For example, it is shown in the android architecture page. Fernando Cejas made it popular, but then changed his mind about this because of feedback from the community. I usually follow an approach similar to this. For small/medium apps I don't split features in api/impl, and my module-injector is inside of app.

I think what we have in place right now is a mix of both, sort of.

We are doing somewhat feature modules. For example, right now we have ui/timeline, ui/settings, ui/welcome. Each of these feature modules contains the relevant UI/ViewModel/Screen(s)/Navigation. There is also a ui/common for shared UI components etc

We then have an ** optional ** domain/use-case layer that sits between these feature modules and data.

Our data layer is also broken up into separate modules: data/network, data/persistence, and data/repository. Here is where it's more by "layer" than by feature.

So we are in a way doing a mix of modules broken down by features and by layer. I'm open to all and any suggestions, changes, etc.

The purpose of this community-led project is to build something fun and useful, but also serve as a community-built example of good architecture, best practices, and bleeding-edge tech.

Originally posted by @crocsandcoffee in #68 (comment)

[lotdrops]

Yes, to this mix is what I refer to. The UI modularization looks good to me, it is with the data and domain layers where I'm not so sure about.
At least from a theoretical point of view, what makes more sense to me would be having modules such as feature/timeline, feature/authentication, feature/search, etc. And in those feature modules, I'd have both the domain and the data. Then, some core or common modules to provide with the setup and utils needed.
That said, I have used ktor and sqldelight very little, and I'm not sure how manageable it is to split them in modules. Maybe it is not doable and we have to stick with data/network and data/persistence...

Originally posted by @lotdrops in #68 (comment)

[thebino]

Currently the projects is using both as you can read in the guidelines

This gives the project the best possible flexibility. Since most of the communication will be shared with all of the modules, it might be useful to keep the data:network shared. But if someone might say, it is better to keep the lower layers inside a feature, feel free to create a draft PR or draw a dependency graph and let's have an open discussion.

I'm myself like the shared mix for this project, but I don't have hard feelings about it.

[mboukadir]

I think it's a good idea to mix the two types of modularization, especially at the beginning of the project, maybe later we can switch to one or the other if we need it.

Based on a script shared by Jake Wharton. I tried to take a picture of the dependency between the project modules:

I wonder if the ui:common module should depend on the data:network. So I propose putting all the pure UI stuff from ui:common in a separate module calledui:design-system.

[thebino]

I don't see any benefit from merging modules, even in the early beginning a clean structure can improve the contribution.

Also ui:common has already ui: as parent.

A dependency graph can be found here in the guidelines as well: https://github.com/AndroidDev-social/MastodonCompose/blob/main/CONTRIBUTING.md#%EF%B8%8F-structure