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)


2 Answers 2


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.

  • 1
    I think this should be the accepted answer. When using the hexagonal architecture it does not matter, whether the other use case (hidden behind the driven port) is another microservice, or within the same application. Hexagonal Architecture enables this transparency. It is just an implementation detail.
    – crushervx
    Commented Jan 4, 2020 at 0:21

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. Commented Jul 20, 2019 at 15:58
  • I wouldn't call these bounded contexts, though. Commented Jul 20, 2019 at 21:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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