Open TristanoSuriani opened 2 years ago
Lets imagine that the external service is not available for e.g. 24h. How do you solve this case with synchronous communication?
Hi Steve, if the external service is not available for 24h, it is no longer a technical problem. You should better think about why are you communicating with a service that offers so low availability.
Option 0: ignore the problem. Not possible? So: option 1: do not communicate with this service. Of course it can be the only possible solution at a certain period of time (but again: a business choice with deep technical consequences).
Option 2: is it possible to ask the team responsible for the service to offer an asynchronous endpoint? Or Option 3: is it possible to use change data capture to send the data to an event log?
No? Option 4: add caching if it makes any sort of sense. No? Option 5: pull data to an internally maintained database.
All these options (and better ones I didn't think about) in case we communicate to fetch data, not to write data (in which case I would put a message broker/event log in the middle to prevent loss of data).
There is of course the case where we do not have to be worried about the external service not being available for long time, which is often the case, when you ask your PO to ask the other PO to add asynchronous communication and the answer is "it doesn't fit in the roadmap" so you do need to communicate synchronously.
But more importantly, what is your take on this?
I think it could make sense to have an example of both synchronous communication (request/response) and asynchronous (event-based) to illustrate both. I'm actually thinking of including this as preparation for the next meetup because I wanted to illustrate contract testing, communication with other microservices & third-party systems.
Thanks @TristanoSuriani , "For example, in case of opening a new account, checking that a person exists and is registered in the country." Synchronous implementation is simple there... @schneidersteve what are your ideas for implementing it asynchronously? (i.e. checking whether person is registered in the country)
@valentinacupac writing asynchronously from the perspective of the use case is the same as writing it synchronously, as it is abstracted by the port. Changing an existing implementation from synchronous to asynchronous would mean changing only the implementation of the adapter and eventually adding some idempotent key to the entity. Some considerations should be made in deciding where to implement logic for deduplication. Should it be treated as a technical concern? Outside the hexagon. Should it be seen as a functional concern? Inside the hexagon.
Reading asynchronously means waiting for an event that triggers a new use case.
A reality we can often observe in real world applications, and even more so in microservices architectures, is communication with multiple services in order to achieve a task. For example, in case of opening a new account, checking that a person exists and is registered in the country.
It would be useful to add an example of communication with a fictional external system to demonstrate the implementation with hexagonal architecture (hint: basically a repository).