android10
Domain separated from Feature, is it a good idea?
Hey all,
I've seen entities and
repositories defined inside the feature, and I thought at first that it is not ideal. Why?
Because it will be used in other modules (features) and failing at the principle of isolation.
So I did what the core package did, I've made a data package for the whole app to use all entities, repositories, etc.
What do you guys think of this? Pros and cons?
I do not see why viewmodel is separate from features, and why network is separate from either core, or data
Not sure what binding is.
@android10 put viewmodel inside core, I thought it wouldn't matter. Network has some modules of DI but its endpoint classes could be inside features but it would be the same case as I stated above about data/domain. Binding is generic classes for android's Databinding component.
@ViperAlpha maybe you will run into issues if you need to modularize your application. if that is not the case, then my comment is not important, and please do not do it if you do not need it.
My idea was actually to extract the core package into a module reusable by other modules, of course I need to work it out, because the approach is still raw in my head but that is something we have been doing while at SoundCloud.
Anyway I have plans to go a bit deeper into package organization and having these discussions is a win. Thanks for sharing!
Thanks for your reply.
I understand what you're saying, and I think it is pretty every related class inside a feature, but I keep worrying about inter dependencies about the modules. In my app, a entity is used across many features.
This article says that it is good only to have a few "public" classes to outside of the package. Do you think having entities/repositories open for other features a good idea?
I would really like your opinion on this, seen that you have a vast knowledge!
By the way, what do you think would be the best approach if needed to modularize the features?
Has anyone come up with a good answer for this? I've always used a package by layer approach and am trying to change to a package by feature for my next project. I am thinking of keeping it as packages to keep it simple at the start but at least if the need arises to create separate modules ( for dynamic delivery or instant app related features ) it should be easier to break down into modules. Anyway, my main concern is that things work well in a small example like the movies app, but in a real project you'll find a lot of overlap with entities, use cases, etc... So if you have everything in a feature package, or even a feature module, how do you handle those shared classes? Do you put them in core? But then it start to feel messy.
Hello, I've used the codebase here, as base module, and created other modules like app, auth, feature, etc. which are again separated with core module on each that consists of data ,domain, use-case. All the modules except the core modules have the base module in the dependency. All the Utility classes are also thus kept in the base module.
My approach is also to reduce the project setup time while doing every new project. Implementing the base module should be doing all the setup, even dagger.
@android10 @Zhuinden can you please comment on this approach, I guess I am not going wrong
Hey all, I've seen entities and repositories defined inside the feature, and I thought at first that it is not ideal. Why? Because it will be used in other modules (features) and failing at the principle of isolation. So I did what the core package did, I've made a data package for the whole app to use all entities, repositories, etc.
Hello, could you please share your code?
You can remove idatasource and repositories and I can almost guarantee your code will be better 😉