jamieadkins95
commented
4 years ago The onion diagram from Clean Arch always has the data layer as a superset of domain. By using that idea we would expect that when adding data as a dependency you would have access to its domain
A nice way of thinking about this is that domain is part of the public API of data, since when you go to data to fetch a list of films, it gives you back some domain objects. You can't use data without also including domain, therefore depending on data should also give you domain.
SAGARSURI
condesales
This is a proposal on how to handle the dependency between modules. I used Jake Wharton's Gradle script with some minor changes to plot the dependency graph to help visualize it.
Original Graph
Proposed Graph
The changes mainly follow the idea of using dependencies as
apiinstead ofimplementationwherever I thought it made sense.The
oniondiagram from Clean Arch always has thedatalayer as a superset ofdomain. By using that idea we would expect that when addingdataas a dependency you would have access to itsdomainI applied the same logic to the cache/remote "data stores" (not sure how you call them)From the original graph, we could also see that
:design_libraryand:navigationmodules are all accessed by the end-feature modules:feed,:actor_detailsand:film_details. I believe the whole idea of a:coremodule is to share all the shared dependencies between modules so moved those asapidependencies there.One interesting case is for the
:letterboxd_api. That module theoretically should only be accessed byremotemodules but we need it as a dependency to:corebecause we need to build the dagger graph and provide it as@Singleton. Perhaps by using@Reusablewe could achieve the same outcome?It's important to be intelligent about what goes into
:coreas dependencies. Only those that are shared across all features should go there as we don't want to provide dependencies that are not needed by features. This could be a big impact on dynamic features.I'm going to leave some comments on specific lines to explain some specific decisions, but the above summarises the whole idea.
I'd love to hear from you the thought process behind the original graph dependencies setup. I dived into this specifically because I was curious to see how other people have been tackling the same problem, so thanks for sharing!