Adapter Pattern: integrating systems without polluting the domain

The real problem

Integrations rarely fail only because of HTTP. They fail because the provider model enters the domain: odd names, foreign states, opaque errors and rules that belong to another business.

When the rest of the system starts speaking like the external API, the integration is no longer isolated.

What Adapter solves

Adapter translates an incompatible interface into your own interface. It does not remove coupling to the provider, but it concentrates it at a clear edge.

That edge lets you change providers, test failures and keep the internal language stable.

How it looks in code

The domain asks to verify an account. The adapter translates provider request, response and errors.

type AccountVerifier = {
  verify(documentId: string): Promise<"approved" | "rejected">;
};

class VendorAccountAdapter implements AccountVerifier {
  constructor(private readonly client: VendorClient) {}

  async verify(documentId: string) {
    const response = await this.client.lookup({ doc_id: documentId });
    return response.status === "OK" ? "approved" : "rejected";
  }
}

When to use it

Adapter is especially useful in modernization and integrations:

• —An ERP or external API has models that differ from the domain.
• —You want to prevent provider errors from spreading across the app.
• —You need to change or compare providers with lower cost.
• —The internal system must keep its own stable language.

When to avoid it

If you only make a simple call and the external model does not spread, a minimal wrapper may be enough. Adapter is worth it when there is real translation of language, contract or behavior.