An adapter is what you write when the interface is not yours

The application already has a Mailer interface and eleven classes depend on it. The transactional-email service being brought in ships a client with a different method name, a different argument order and its own idea of what a recipient is. An adapter is the class whose entire job is to be the shape everybody already agreed on.

interface Mailer
{
    public function send(Message $message);
}

// what the vendor gives you:
//   $client->deliver(array('to' => ..., 'subject' => ..., 'html' => ...), $tags)

class VendorMailerAdapter implements Mailer
{
    private $client;

    public function __construct(VendorClient $client)
    {
        $this->client = $client;
    }

    public function send(Message $message)
    {
        $result = $this->client->deliver(
            array(
                'to'      => $message->recipient()->address(),
                'subject' => $message->subject(),
                'html'    => $message->body(),
            ),
            $message->tags()
        );

        if ($result->status !== 'queued') {
            throw new MailNotSent($result->reason);
        }
    }
}

The difference from a facade is which end the interface comes from. A facade invents a simpler interface over something complicated, so its shape is a design decision you get to make; an adapter conforms to an interface that already exists and already has callers, so its shape is fixed and the only question is how to translate. That is why an adapter is usually mechanical, and why the interesting part is always the mismatch — here, a failure the vendor reports in a return value where the rest of the application expects an exception. Where the two genuinely cannot be reconciled, an adapter that lies is worse than no abstraction at all: a send() that swallows a failure because the vendor answers asynchronously has changed a contract eleven classes are relying on. Widen the interface instead of hiding the difference inside the adapter.