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.