In HexagonalArchitecture you write an AdapterPattern against your external dependencies. 

It's important that the adapter add actually do something. Don't write a 1-1 adapter to a new, identical interface. For example, in C#:

    interface IFileSystem
    {
        void DeleteFile(string path);

        // etc. - every method on File, Directory, and Path are here.
    }

    class FileSystem
    {
        void IFileSystem.DeleteFile(string path)
        {
            File.Delete(path);
        }
    }

This isn't really an adapter, since there's no real abstraction being created: it's not abstract.

'''Concerns'''

This lets you ignore the need for a new, valuable abstraction. Your tests are giving you feedback and you're suppressing that feedback. That abstraction should be a little higher, so that it can hide the ugly details of the dependency that you don't care about. 

'''Exceptions:'''

* The adapter is actually one level higher abstraction than the dependency (e.g. "File System" becomes "Blob Store")

* The adapter adds some functionality that was missing originally (e.g. transactions)

* Replace primitive-type parameters with a ValueObject (e.g. `string` becomes `FileSystemPath`)

* The new interface maps terminology from the dependency in to your domain.

* This is the first step in a series of refactorings, which will create a useful abstraction later.

* You can't refactor, due to time, risk, or skill constraints.

* The new interface is a narrower subset of the external interface.

* The new interface hides something ugly about the external interface.

[CategoryAntiPattern]