Refactor project structure to one single module?

[android10]

Hi guys, as you can see I have been working on a single module project structure.
Here is the PR: #103

I'm not saying that I will land it but I do want to start a discussion around it and see pros and cons for either a single module project or multi module project.

The first couple of things that came to my mind:

Advantages:

• Scalability: package organization into features so working with a feature team model will fit better, specially when the number of contributors to the codebase is big.
• Scope: favors exposure to only necessary members (removes many public methods from feature specific classes).
• Build System: less overhead since building logic sits on only one project and we do not have to maintain many build.gradle files for each project (better performance?).

Drawbacks:

• Clarity: by having 3 modules, each layer responsibility is very clear.
• Dependency with the framework: By having only one android module we are exposed to make mistakes and break both dependency rule and dependency on android/java framework.

A few extra eyes are very appreciated, so let's try to find the best way to keep on improving this codebase.

@spirosoik @Trikke @caseykulm I mention you guys since have been collaborating a lot. Thanks! Feel free to involve anyone here 😃

[Trikke]

Thanks for the mention, @android10! I'll just give my two cents here and bring some points up for discussion so we can hear everyone's ideas about them.
I've taken a quick look at the current branch. I'm a fan of "package by feature", but that is usually incrementally more difficult to implement than "package by layer". It can be hard to describe layer bounds and make mistakes against the layered architecture. I already like the work you've done on that branch, and here are a few ideas/remarks.

That core package
I've never liked packages that very broadly named, "core", "util", "ui", "helper", ... So i'm wondering why that "core" package is needed? Because anything under the "view" package could also be classified as part of the "core" of the app, so should that also go under "core.view"? I'm in favour of dumping the "core" package. The "di" package is as much of a feature in the app as any other. If a coworker wants to switch to a different DI framework, they should easily find that feature.

Package by feature, then by layer
Another idea is to first package by feature, then package by layer. For a simple sample app as this, the "user" feature is already quite full of classes. What if you'd even further split up each feature by layer? This would make sense if you have large feature teams working on your app and have guys responsible for UI, others are experienced in data access and so on. I've quickly drafted a treeview to give you an idea.

app
└───user-feature
    ├───data
    │   │   UserRepository
    │   │   UserDataRepository
    │   │   ...
    │
    ├───domain
    │   │   GetUserDetails
    │   │   GetUserList
    │   │   ...
    │
    ├───view
    │   │   UserListActivity
    │   │   UserListPresenter
    │   │   UserListAdapter
    │   │   ...
    │

The other feature packages make sense. A package for the "navigation" feature. A package for the "data retrieval" feature, and so on.

These are just a few ideas and are mainly meant to fire up the discussion. I'd be happy to hear anyone's thoughts. If i have so more time, i'll go over the branch in more detail.

[malan-malanowski]

Hey,

think about using veripacks in this approach so application flow would go as intendent (view -> domain -> data).

[spirosoik]

Hi guys. thanks for mentioning @android10!

I will go over the advantages to describe my thoughts as I am as supporter of the 3 modules/layer approach.

Scalability: I think that this depends on how the team is structured. For example for a very big organisation there are teams for specific layers/modules in every kind software (mobile/web etc.) . I think that the package by feature makes sense on presentation and domain layer where it's much easier to apply it and maintain it. The data and the core layer must be abstract, independent and must expose only the necessary things which will be used by the upper layers. The data and the core layer must be able to run their tests without any dependency in the domain and the presentation layer. For sure in a 3 modules/layer approach it can be a 4th core module. This is the approach which we are using here also we have a separated core module but not for DI or views. We use it for some tools which we want to be available in every layer.

Scope: I think this can be done easily with current implementation also but it needs changes using the DI. I will refer again the Effective Java book and especially the Item 13 Minimize the accessibility of classes and members. This can be done with Dagger2 according to different modules, components and scopes. That's why the Dagger2 give us power.

Build System: I think this is not valid as there are plenty of optimisations and techniques which we can apply and boost the performance of the build process.

Now for the Drawbacks section I want to note the Dependency with the framework which is very very important. Many Devs use context anywhere they need without think about, "is it really needed here?" and then the Business logic is coupled with the Android framework. So if we have a clear independent java module, for me raises automatically the rule do not couple the business logic with the framework. This will help the team for code reviews also. Imagine that a newcomer (even a mature member) starts writing code and the code reviewer realises that the whole business logic or part of it, is coupled with the framework (I know that we setup rules by the first day but it's possible to have such kind of mistakes).

Lastly which you didn't mention guys and I think it's very important is that with this kind of approach we aren't able to run the different layer tests independently in a CI environment and in the development process. With the one module approach it's obvious that I must run every test which it's not efficient. Yes I know you can do it via Android studio (for dev process) but there are different scenarios when I am using a CI and I want to have different kind of build processes.

That's all guys, these are my comments :) . So food for thoughts.

This kind of discussion would be great to be done in a pub with 🍻

[Rainer-Lang]

I like to have a "feature-structure"...
“Package by features, not layers” @cesarmcferreira https://medium.com/the-engineering-team/package-by-features-not-layers-2d076df1964d

[Rainer-Lang]

Look at point 10 and especially 15 ;-)

https://medium.com/@cesarmcferreira/building-android-apps-30-things-that-experience-made-me-learn-the-hard-way-313680430bf9

[Trikke]

Hi guys,
I had a small brain fart about this. I think @spirosoik makes some valid points, and most people are sold on the current module setup of this project. It's mentally easier to organise and everything that @spirosoik said about that setup makes sense.
I'd like to throw around the idea keeping the "layered module" setup(or even refining it more) and then packaging everything by feature. Currently this is not fully the case. If you would/could view it from a high level in some Tool Window in your favourite editor and merge packages from all modules, you'd essentially see everything packaged by feature.

If you look a the current structure, you come across packages as "repository", "interactor", "presenter", ... which indeed contain all related classes. The "repository" packages contains the "UserRepository", the "PhotoRepository", the "WhateverRepository". I think we should split these up by feature. Here's a package tree to clarify it more.

data
└───repository
    │   DefaultRepository
└───cache
    │   ACacheImplementation
└───user-feature
    │   UserDataRepository
    │   UserSqlCache
    │   ...
└───photo-feature
    │   PhotoDataRepository
    │   PhotoFileCache
    │   ...
    │
domain
└───interactor
    │   ObservableInteractor
└───user-feature
    │   GetUserListInteractor
    │   GetUserDetailsInteractor
    │   UserRepository
    │   ...
└───photo-feature
    │   GetPhotosFromUserInteractor
    │   PhotoRepository
    │   ...
    │
presentation
└───navigation
    │   Navigator
└───view
    │   BaseActivity
└───user-feature
    │   UserListPresenter
    │   UserListActivity
    │   UserListAdapter
    │   ...
└───photo-feature
    │   PhotoBrowsePresenter
    │   PhotoBrowseActivity
    │   ...
    │

This way, we keep certain features (navigation, caching,...) in their current layer and have the features of what our app actually "does" grouped in their respective packages.

[Rainer-Lang]

@Trikke I like your "fart" ;-)
I find your suggestion will help to keep a good overview over the features - but keeps the 3 module structure. I see the big advantages to have all separated in modules. This makes it easier to avoid mistakes.

[android10]

Nice discussion guys. I see there are mixed feelings around this PR and honestly I don't see any solution better than the other.
One thing to clarify: when talking about features, I mean user facing features, so the rest of the packages don't count here: for example core and di are used to organize and group infrastructure stuff, things that are part of the app and used across it. Cache is not a feature nor util or helper.

[android10]

I might not merge this PR for now but I will link this to the articles so people can participate and leave their 2 cents on this approach.

[Trikke]

@android10 in another issue you talked about working on projects at Soundcloud where projects exists within a single module. Is there a difference in setup between those and this PR? Or is the 3-tier module setup something you created because you liked it more, reflecting on your work at Soundcloud?

[android10]

The 3 module project was an initiative to completely run away from android, specially on the domain layer which is a pure java project favoring unit tests, since a couple of years ago, it was very difficult to setup robolectric and junit so you had to create a separate module to test another module. (that does not happen anymore fortunately, buy you can check the history of this repo when I got rid of it).

As I put in the description, I think 3 modules bring a little bit of overhead and that is the reason why I wanted to start this discussion (plus the other disadvantages I mentioned in the description). I'm not saying our solution at SoundCloud is perfect but wanted some input and thoughts coming from the community). Also we are not using a pure Clean Architecture approach, although is similar.

If you are curious about how we work and have a taste of how our app works here are 2 interesting videos:

https://www.youtube.com/watch?v=R16OHcZJTno
https://www.youtube.com/watch?v=uHy_54Dpcj0