I'm wondering, is it worth splitting the project in 3 big gradle modules, that depend on another. Let's say

:A -> :B -> :C

. I know it's not ideal, but I don't want to burden my team on a time constrained project. It brings some challenges, that we're not used to. Is it still worth doing, or should I simply keep it a monolith? I'm guessing it would be better for the future, to at least same some basic module structure, so it could potentially be refactored a bit easier, if needed.

It really depends on how big the project is and how much bigger you’re thinking it will grow

This will not help much in build speeds as the graph length will be large and ideally you should have as small a graph length as possible for better build speeds. If you are thinking of keeping A, B and C as different layers like UI , Data Source , Domain I would advise against that . It is better to split it into independent features with no dependencies between them . A very common practise is to split features into private / public (or api/impl) modules .

Besides splitting on feature module and small graph length, I’d add keeping modules small which allows you to build with smaller heap for your Gradle and Kotlin daemons. For instance if you have a 32GB machine but you need 12GB heap to build the app at all, you’re going to have Gradle and Kotlin daemons each take 12GB and then not spawn additional worker daemons because you can’t satisfy the heap requirements (12 + 12 = 24, and with only 8 GB left a new worker will not be created). This means that you end up with a pretty serial build in reality whereas a codebase that has many small modules and does not need to have as large a heap per module would be faster. There is a configuration time tax that starts around 70-80 modules though, so if you start going beyond that you’ll see significant time spent just in the configuration phase. Gradle Configuration Cache mitigates this as long as you’re not changing any build files or flags, but its not yet easy to get it right as some plugins are still not CC-compatible.

I'm not looking to improve build speed atm, just having a clear separation for now. We still organize code per feature, as much as possible. For example, I have one module that joins data+domain logic, inspired by this article. I felt it would be a good idea, since it still fits into the general architecture of the article. My idea was, that it would be easier to refactor that module into multiple data+domain modules, if needed.

Try to split your app into feature modules rather than layer modules , It gives better separation and later on you can split the individual features into layer.