I'm currently in the process of transforming a monolithic application to a microservices based architecture. The monolith is dependent on third party services (as in other departments) for its data. Most of these third party services are accessible via SOAP while some of them use REST.

Some of these third party services have terrible (even unusable IMO) APIs. It adds a lot of unneeded complexity and boilerplate to our aggregator service (which is a monolith atm). I'm in the process of mapping the domain of one of these third-party APIs to a usable domain in an ACL to be able to offer a decent API to our aggregator service.

However, it got me wondering. Is this even the correct way to go? It's a lot of work, should I just bite the bullet and use those terrible APIs? How do you handle terrible third-party APIs in a microservices architecture which make your service less maintainable?

Thanks in advance!

  • Could you just clarify: are you saying that you use the ACL to map to the domain concepts within your service (for the specific needs of the service), or that you are designing a separate domain model for the ACL, and then offering a generalized API to sort of replace the existing one (i.e, it's not specifically geared towards your service)? Commented Feb 19, 2020 at 20:57
  • 1
    Does this answer your question? What is an Anti-Corruption layer, and how is it used?
    – gnat
    Commented Feb 19, 2020 at 21:38
  • @FilipMilovanović I'm designing a separate domain model which is mapped against the third party's model in this ACL. So, the ACL offers a generalized API using this domain model. Commented Feb 20, 2020 at 6:59
  • @abstractchristmastree - although an ACL can be complex, if I understood you well, what you are doing seems to be making things needlessly complicated. An ACL should just do enough to translate between the models of the two systems at the specific points of their interaction, not introduce a model of its own. So, not a generalized API (you are not trying to make a better version of the 3rd-party service), but an API that just covers the needs of your service (so that you can write code in terms of your own model). Commented Feb 20, 2020 at 8:12

2 Answers 2


I encounter this type of thing all the time, there are some unbelievable commercial SOAP/XML APIs out there. What I normally do is basically two things:

  1. Define a facade for the functionality my service actually needs. This is a simplified interface that exposes the things my service cares about in a consumable way.
  2. Create an adapter between the external service and the facade. This adapter interfaces with the terrible 3rd-party service and hides all of the detail. It then implements the facade interface that my service consumes, so all my service knows is how to use the facade.

This has worked pretty well for me, and it has the added benefit that if you ever move away from the terrible service to a better one, you can simply implement a new adapter without changing anything else, since your service will still just consume the facade.

  • Thank you :) But how do you go about sharing the domain model? I'm currently mapping my own domain model against that of the third party service in the ACL. Tools like swagger-codegen can then generate a client, including the models of my mapped domain, in my aggregator service. Commented Feb 20, 2020 at 7:00
  • @abstractchristmastree That can depend on your technology stack a little bit, but I would generally define the facade in terms of my own domain model. The adapter then maps between that and the 3rd-party domain. Commented Feb 20, 2020 at 15:39

Yes, you should have a microservice to call/hide the third party API. That service's job is to know how to call the third party API. Not only because it's messy, but to avoid carrying the idiosyncrasies and implementation details of the third party service into your design. Also, this gives you a chance at abstraction or generalization. You can then switch out the API or even switch to a different technology behind the scenes.

Such microservices are often doable without persistence, don't change a lot, and will not require much maintenance once created. It will allow you to drive your own best practices, like having a health check endpoint, token authorization, etc. into that domain instead of their domain dictating it.

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.