Is it good to have a use case depending on another use case where the other use case is just forwarding the calls to the repository ?

if it’s the pattern to have usecases that are just delegating calls to repository and you already have usecase that does what you need than it’s ok to depend on it

I agree with @Marko Novakovic. It's just a high lvl code and doesn't break unidirectinal flow

What if in future I add a business logic to the usecase which is now just forwarding the calls to repo..

It depends what kind of logic and in what situation.

just don’t duplicate code. if you end up adding code to some usecase that you depend on and it’s not suitable any more for some other usecase, create new usecase or call repository directly

I was thinking of not having a usecase just to forward the calls to repo instead directly call the repository The current usecase class UseCaseA(val usecaseB: UseCaseB) { fun execute() { useCaseB.saveData() } } In the above example usecaseB is just forwarding the calls to repo instead i would prefer to directly inject the repository

as always, i'd just remove the repositories and move all that code into usecases that don't depend on each other

interesting, why not? if, for example, you already have some non trivial behaviour covered with a usecase, why not use that usecase if you need that exact behaviour?

A UseCase can be a meta UseCase and have part of it’s responsibility/task be executed/delivered by other UseCases and work on the result to achieve the final responsibility. But, if it is only about a UseCase delivering some other UseCase result directly then my suggestion would be to use the original UseCase directly. Every UseCase should follow SRP and should have only one reason for change. In your case, you are still going to violate DRY if you copy the same responsibility from existing UseCase.

I would make the use case being a custom kotlin flow operator and concatenate them if one depends on the other output. That way you gain a free coroutine scope already in the flow {} builder

We do that all the time in my company. Our project is heavily modularized and focused on clean architecture.