I feel like it warrants its own package, but its n...

# android-architecture

[ursus]

I feel like it warrants its own package, but its not a ui facing feature like news or weather, where should I put it? account/ package in root? in data/? if root, then data/ already has MessageRepository etc, wouldnt that be a mismatch?

[ghedeon]

sounds like another feature to me, so probably feature/account/{data, domain, ui}. But it's not clear what architecture you're following, I'd expect "net" inside data package. Also, depends on the size of the app, eventually you want to start using modules.

[ursus]

well Im following package by feature, but not clean per say but I dont think it matter, within your feature you can split it up however you want. What im strugling where to put shared stuff like net, utils, and some repositories

[ursus]

should it be just root or some explicit /core ?

[ghedeon]

maybe solve problems as they come. If the poject is big enough and you follow clean arch terminology, you'd probably have app module that connects core + feature1 + feature2, etc. The core itself most probably could be splitted in coredata, coreui modules... It really depends on the scale. For a trivial app your main module is `app`+`core` by default, so you can have:

app
     - data // shared
     - domain // shared
     - ui //shared
     - features
            - feature1
                     {data, domain, ui}
            - feature 2

Later, shared stuff can go into core module and each feature to its own module.

[ursus]

yea thats more or less what I have, but where would you put a "intrastructure" thing like AccountManager? its has like 5 classes associated with it, id feel bad spliting it into coredata and coredomain

[ursus]

by core now should I understand (from the above)

- data // shared
- domain // shared
- ui //shared

?

[ghedeon]

yes. Again, it will be easier for you if you follow a specific architecture pattern. Because then you don't have to think too much "where I put this or that". Roles are defined for you. I don't know what's AccountManager. But if it's kind of repository role from Clean Architecture, than its interface goes to domain and implementation goes to data package, because of the inversion of control.

[ghedeon]

Maybe try to read a few articles on this matter, so you have a clear structure in mind. You'll find Clean Architecture sample apps in Google samples repo.

[ursus]

I dont really like the formal clean architecture, i.e. having everything inherit from UseCase

[ursus]

but as a composition its okay, but the meat is still in manager, they just call it repositories, afaik repos used to be just gateway to data

[ursus]

in simple apps okay, but think sync.. should it be a Syncer which takes repo or a use SyncUseCase? idk