Using Gradle, for Android native development, when you modify code within a module and hit build, said module and all modules that depend on said module rebuilds. This usually is helpful, but I find myself creating lots of data classes and mapping them, usually to another data class that's exactly the same. In some cases these mappings make sense, for instance, the view entity usually has less data, or transforms a string, that when mapping into the domain module that needs changing, and the firebase entity might have a field with a firebase annotation, or it might have a new field, or less fields that are saved into the database. But some other cases, usually within the domain and firebase service layer, these two data classes for the same "business entity", are the same.
For instance, the presentation module maps a view entity into a domain entity, then the domain module might have to map that entity into a firebase entity within the firebase module, because the domain module has no knowledge of the presentation module, and the firebase module has no knowledge of the domain module and their classes.
This works and whenever I need to change something within the firebase module, only the firebase and the domain modules are rebuilt. But I had the idea of creating a shared entities module called "entity" which is a pretty common pattern I see, but now many modules depend on this new "entity" module. So whenever I add or modify a lightweight data class within this module, the "entity" module and all other modules that have a dependency on it are rebuilt. For instance, in the example I mentioned above it would be "entity" module, firebase module and domain module (plus any other module within the app that depends on it). So my question is: should I keep creating lightweight data classes and parsing them from module to module (which seems to be the correct choice for me) or do I go this shared entity module path?
