Search code examples
web-servicessoapclean-architecturehexagonal-architecture

Design of a service dependent on SOAP API which changes a lot

I'm refactoring a service which is dependent on a SOAP service. Unfortunately the SOAP service changes regularly. My service uses classes generated from SOAP's wsdl document. There is no layer that would separate entities defined in the SOAP service from my logic. In other words the SOAP service leaks into mine and its changes cause problems.

I want to fix that. I'm considering an approach in which i create wrappers around the generated SOAP clients which would conform to an interface defined by me. The wrappers would be responsible for:

  • translating to/from my interface to what is comming from the SOAP service and what the proxy requires
  • calling the service using the wrapped generated client

This way i would limit the impact of changes in the SOAP service so that only the wrappers are affected.

I think this is how it should work according to the "ports & adapters" architecture. Is that approach correct? Can i do it better?

Solution

  • I think your approach is perfectly valid.

    I'm considering an approach in which i create wrappers around the generated SOAP clients which would conform to an interface defined by me.

    In hexagonal architecture the interface defined by yourself would be the port and one adapter implementation of this port would then be what you call the wrapper. This wrapper (i.e. adapter) utilizes the SOAP service to communicate with the outside world and makes sure it conforms to your interface (i.e. the port).

    In terms of object-oriented code the port itself would be an interface and the adapter would be a class implementing this interface which has the dependency on the infrastructure - the SOAP client.

    So with that, your application service depends on an abstraction (the port interface) rather than implementation details (the infrastructure part - i.e. the SOAP service).

    enter image description here

    When implementing this approach just make sure that neither your application layer nor your domain layer directly depend on infrastructure, i.e. adapters, but rather on interfaces (ports).