About common-domain module
opened this issue · comments
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?
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.
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.