We are fairly new to hex arch in my team and trying to figure out best implementation for various scenarios.
Most examples online illustrate the typical use case having command/query -> use case -> db/msg/api
One scenario that has caused a lot of debate is async response handling (e.g. response topic, http callback, polling remote endpoint)
Assumptions:
- Driven ports should only be called by Application Layer / use cases
- Use cases should only be called by Driving layer
In most modern frameworks, you implement a method that acts a server for consuming messages or accepting HTTP responses. e.g. @kafkaListener, @RestController, @SqsListener.
Having response handling in driving layer aligns very well with these abstractions for messaging and api.
Handlers consequently needs to call some sort of implementation. (e.g. use case)
On the other hand, Alistair Cockburn described secondary actors/driven layer as handling a conversation with another party. The argument here is that async response is part of the same conversation.
Keeping response handling in driven layer makes it easy to switch to Sync later. However this adds overhead and complexity. e.g. by having app layer as orchestrator to poll for responses
What are interpretations of this out there?
Response handling in driving side:
Response handling in driven side:
