mars885 / gamedge

An Android application for browsing video games and checking the latest gaming news from around the world.
Apache License 2.0
689 stars 65 forks source link

About common-domain module #210

Closed ghost closed 1 year ago

ghost commented 2 years ago

Hi thanks for a great sample about modular application with compose. I'm curious about why are you seperate common-domain instead of adding domain package in every feature modules?

mars885 commented 2 years ago

common-domain & common-data exist purely out of the reason that two or more features require access to the same use cases. Putting them inside the domain & data module of some feature will require importing the whole feature, including domain, data, and presentation subpackages. This is not ideal, since we want to just have access to the use cases & don't really care about the presentation.

feature-discovery & feature-category both use Observe*GamesUseCase & Refresh*GamesUseCase. Therefore, they are put into the common-domain that is included then into both feature-discovery & feature-category modules.

Hope it helps.

mars885 commented 2 years ago

Btw, common-domain & common-data modules are also not ideal, in my opiniom. The reason being is that, sooner or later, they are bound to become monoliths, since quite a lot of use cases may be reused across features when the app grows.

The better idea is having some common module (e.g., common-games) that will have two subpackages called domain & data. Then it'll be quite easy to plug them into features that actually use them. In that scenario, common-domain and common-data won't exist at all, since everything will be extracted into corresponding reusable modules (e.g., common-games, common-auth, common-news, etc.) & the monolith problem is resolved. However, I haven't tried that yet, but that's definitely looks much better than the current approach of having just common-domain and common-data modules.