Closed ghost closed 1 year 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.
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.
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?