Mimic Adapter

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]