My layers are like:

Controller (Http) -> Use Case -> Domain Services

Imagine that I have a PurchaseController which is just getting the parameters from the Http Request and calling the PurchaseUseCase.

This PurchaseUseCase is using some domain services (like an OrderRepository, etc)

But, it needs also to get information or deal with another context.

Is it ok, for example, call the GetUserInfoUseCase (it's in another context, and I feel coupling context), from the PurchaseUseCase? Or should I use a Domain Service (for example a UserInfoProviderService) from a shared kernel?

In resume, the question is, can a UseCase call another UseCase (from another context)

If it would be an action that I can fire and forget, I would use an event and listen to it from the other context. But it's not the case, in this case, I need to retrieve some data from the other context or validate some info (like if the user has enough money, whatever)


From your question, it is clear that the functionalities belong in separate bounded contexts. So the straightforward answer would be No, you shouldn't.

It is good to assume that someday in the future, given sufficient scale and performance requirements, each bounded context will become a Microservice of its own.

So if you want to use some functionality in another context, you would generally access it via a well-published API, like a method in an Application Service, an API, async over a Messaging Medium, etc.

  • Agreed. When using something, prefer the front door even when you have access to the back door. Back doors don't tend to be maintained that well. – candied_orange Jul 20 at 15:58
  • I wouldn't call these bounded contexts, though. – Filip Milovanović Jul 20 at 21:05

Reading the whole text of the question, title should be: "Can my use case implementation call a use case of another remote application (hexagon)?" The answer is yes. You should create a driven port for that. The driven adapter would do the remote call.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.