dvdstelt
commented
4 years ago Hi Marcel,
TL;DR: It has to do with transactionality, that's all.
I think I understand your question. But if not, please let me know. IT/OPS is responsible for integration, because most of the time, integration requires gathering information from various services. And Finance or Shipping cannot gather information from other services. IT/OPS also cannot, that's why it defines an interface. That interface can be implemented by any service that thinks it needs to supply data. And IT/OPS simply calls every implementation of the interface. This way it's decoupled as much as possible. Because IT/OPS
- has no idea which services will provide data
- doesn't need to change when additional services need to provide data
- has no idea what data will be provided. It just collects and passes it on. This works especially well in ViewModel Composition scenarios, where each part of the UI (or email) is the responsibility of some service. But with integration scenarios like a payment provider, not a single service can be responsible for the 3rd party API and thus we put the responsibility with IT/OPS
Now take email and smtp server as an example. Theoretically, we could process a single message with a service (Finance for example) and then call IT/OPS and have it send the email. However smtp servers are not transactional. So if an error occurs and the message is retried, the email will be sent again. Thus instead we decide to send a message to IT/OPS, instead of calling it in-process.
If we just need to query some 3rd party system, there's no issue at all in calling the IT/OPS component in-process. Especially if Finance holds all the information to be able to query the other system. Even if the request is idempotent. Like a creditcard charge for a hotel room. We just ask the credit card company to reserve the money for a specific order, providing it with the unique order identifier (or a unique key that can be mapped to the order id). No matter how often we request it, the result will always be the same. Those can be done in-process as well.
I hope this makes sense. You can always contact us at support at particular.net or visit the ADSD Alumni forum for which you should've received an invitation during the course?
marcelbraakman
When I attended the ADSD course last year in London, Udi said that ITOps is responsible for integration (+email) and hardly ever subscribes.
In the exercise about integration, Shipping sends a command to ITOps. But I was expecting a different implementation. Something like the PaymentClient in Finance, only then implemented in ITOps. Udi showed this in an example where he build the integration with the 3rd-party payment provider in ITOps. And Finance would call this in-process and not via messaging.
Is there a specifc reason why this workshop is using a different strategy? Both seems fine to me but I'm trying to understand both concepts.