Glad it was helpful!

I very like separate project into features-modules, and i think that it is the best way for clear, convenient and easily expandable architecture of Android App) yeap, i have read your comment, and understand that we can use it in any project, not only Android, but i have experience only in Android and KMP) For your problem sharing of data between 2/3/4 (as u want) modules u can use next way: in my project i use 2 modules - api and impl inside feature-modules, all private logic i put in impl module (repositories and usecases implementations, screens, viewModels, uiModels and etc.. Also i put here DI and retrofit Api Interfaces, but it depends on situation and di libraries for example). In Api module i put only data for sharing. For example: UseCases and Repository Interfaces if i need to share it, maybe data layers mappers if need(more often not), maybe sharing constants, domain models for sharing usecases and screen parameters, which i need to get for screen start (for example id of user). In this case any your feature module has dependencies only for api modules of other feature-modules and knows nothing about feature-impl modules. And your Api module is really small and light. And in this way you can implement your feature-api module only in those modules what u need. Also this way help your improve building time, cause u have dependencies only for abstractions or rarely changeble classes as ScreenParams, and it means that u feature-module2 with dependency feature-module2-api will not rebuild after each changes in feature-module2-impl architecture scheme looks like: --feature-module ----api ------data ------domain ------presentation(here presentation layer needs me only for sharing of screen parameters if it's neccesary) ----impl ------data ------di ------domain ------presentation

@@okunevdmitrii Your approach surely works, but to me it looks hell of a complication! Having all modules having a separate part declaring all their shared classes as interfaces so that they can be injected by DI into sibling modules makes quite hard to figure out how the whole project is structured as it scales. I'm sure most projects can be organised fully in feature modules like Phillip described but in the ones I happened to work, backed provided those very large APIs that returned very interconnected data, and that kind of approach never worked. What I found is best in those situations is just to consider your "app" just the presentation layer, and divide it in feature modules accordingly, with just one module providing shared UI resources. Domain and Data can be while modules that behave like libraries for your UI, data providing repositories that internally manage data sources and domain exposing use cases and models. This also allows me to organise the three layers differently: for example, the division in features that makes sense on the UI level might not be very relevant to the domain layer that could instead group use cases by area of influence, and the data layer could group repositories and data sources around the actual Apis provided by the backend. Forcing a singular organisation vertically for the whole app rarely comes natural.

​@@Drackmord92 that last approach is just what we've been doing in our last project. But that doesn't mean that if you want to have domain/repositories/all-your-repositories it's a mistake. At the end of the day, it would be exactly the same code (same clean Architecture guidelines), with a very subjective way of organizing how your team edit and visualize it. You can think this as a flatten version of feature oriented, which can be easier to read depending on the team or the project. Don't take me wrong, I will always prefer the feature oriented version, but is not a mistake by any means doing it the other way. Also ​Philipp, keep going with your videos mate, you are doing awesome!

Tbh, if a 'feature' can operate independently from the other 'feature' u should probably put it in its own module/package. I've never made a native android app but worked with other frameworks (Flutter). Feature is something to figure out for later, because it forces you to think about what will work with what en where. You could say: plan better, but in my experience plans will always change in development because of unforeseen problems. The argument: "it's better because all the related files are grouped together" is non-sense, because with most IDE's you can just click on the import to jump to the source.

I tried the feature-approach as well, and I "solved" your problem by having a 'shared' package with data, doman, and presentation. Problem was though, I ended up puttin so much into the shared-package, that it sort of negated the feature-approach lol

PROPER Regex is incredibly difficult to write and maintain lol (most codebases that do this just go with a contains([@.]]-approach. There's absolutely no shame in using a validator library

I also

They exist for different purposes. Repository works with data and that's it. Use-cases contain valuable business logic. As an abstract example, it may get data from one repository, then pass its output to another repository and in the end aggregate it with another data. If use-cases just proxy repository calls, you should reconsider their necessity. View-model maps data from use-cases to UI-friendly structures and receives UI events. These all are different cases for testing. In repository you test correctness of data logic. In use-case you test correctness of business logic. And in view-model you test correctness of presentation logic.

​@@vasiliychernov2123 "In use-case you test correctness of business logic" - so by what you say I see that use-case testing is indeed necessary, which goes against what Philip said in the video

@@alonshlider4881 Uhm, Philip literally said that use-cases are being tested.

🔝🔝🔝🔝🔝🔝🔝🔝🔝🔝 *Thanks for watching you have been selected among the lucky winners, inbox* MOGSWAMP 🔝🔝🔝🔝🔝🔝🔝🔝🔝🔝🔝

🔝🔝🔝🔝🔝🔝🔝🔝 *Thanks for watching you have been selected among the lucky winners, inbox* MOGSWAMP 🔝🔝🔝🔝🔝🔝🔝🔝

@@Mogswamp- 🤣🤣

@@Mogswamp- @PhilipLackner just see this haha

Data layer deals with SDKs and APIs. The Android SDK is therefore partly data related

@@PhilippLackner alright, gotcha!

data layer depends on domain layer - it's ok. domain layer doesn't depend on any module (except any other domain layers)

@@anegine The use-cases in the domain layer can access the repositories in the data layer and now both the domain and data layers are depending both ways right?

@@VishnuHaridas Domain layer MUST NOT depend on data layer. Domain layer contains Repository interface. Data layer contains Repository implementation, which is injected to domain UseCase (with DI / ServiceLocator or any other way).

@@anegine Oh deja-vu! I have seen similar conversations before when Google introduced the "layered" architecture where domain depends on data layer and not the other way around. I think it will be good to clearly specify that this is not the official "layered" architecture recommendation when making videos on Clean architecture on Android, otherwise new developers can get it mixed up.

nice

Why inject it if you can just make it an extension function to not need to inject it anywhere 😅 you don't gain anything with that interface

Extension function is better to keep responsibilities separately

in the core package

Why would you need a fake mapper?

to test something

Regarding the second thing, that's similar to what I suggested in the video. I was referring to people who use presentation, domain and data packages and then don't use features in these. That's quite common

@@PhilippLackner To be absolutely honest your approach kinda better. For me having data-domain-presentation in this order from top to bottom in package manager is more menthal thing, carried from times before clean architecture and even Android development.

if you're going to test your use cases, inject repos as interfaces and mock those interfaces in tests

@@wetfloo First thank you for your answer , Yes that's what im using (interfaces) but i was asking about to add Hilt dependency in the domain Module.

@PhilippLackner 🤔

@@boukarradhmoez99 I didn't understand your question. Rephrase it, please?

@@boukarradhmoez99 Repositories are defined as an abstraction so you can have 2 different implementations - 1) the entity, which is the real implementation (which is most likely done in data layer) and 2) usually mocks for your test cases. On Philips' example, he didn't need to create 2 different implementations of a use case, because the the actual implementation of the use case, the business logic itself is what he wants to test. If you're wondering why don't we test the entity of repositories - it's simply because it has direct correlation with data (retrofit responses, rpc calls, room, cache, online configs, whatever) and you don't really care about that in your tests. Another reason is you obviously don't want to actually hit an API on your test cases

🔝🔝🔝🔝🔝🔝🔝🔝 *Thanks for watching you have been selected among the lucky winners, inbox* MOGSWAMP 🔝🔝🔝🔝🔝🔝🔝🔝

Why would you want to pass fake business logic? What's the point? Use cases are always isolated logic, there's zero reasons to abstract that

​@Philipp Lackner If we didn't abstract usecase then all usecase will be tightly coupled in view model right doesn't it break the DIP principle. Also if we want to test the viewmodel which contains the actual implementation of usecase how you will test it. My suggestion would be to upload a separate video describing this will be helpful for us. Thank-you

​@@PhilippLacknerIn the context of use cases, it may be necessary to create a mock implementation of a use case in order to test the code that calls it. By creating an interface for the use case and passing in a mock implementation during testing, you can test the code that calls the use case in isolation, without having to worry about the implementation details of the use case itself.

Any update regarding my query?

It's not necessary, but it's easier to maintain your app and add new features. You won't gain any performance boost though or might be an overkill if your app is very simple.

@@jarkow Thank you

It is not. I'm pretty sure even Google says domain layer is optional. If the only thing your use cases do is call 1 method from your repository, then you should throw them away. If you don't even plan to write unit tests, you probably don't even need to abstract your repositories. Clean Architecture is not really a concept from Android, it's used across all domains (iOS, Web, Backend, etc) and it only matters when you have scalability in mind. That said, IMO even on small apps, it's probably still not too good of an idea to put everything in your activities tho...

It's definitely not necessary

In my experience, it very quickly leads to over engineering if you abstract everything while it comes with pretty much no benefit. You either want multiple implementations or really need to abstract stuff to use it in domain