Some years ago, Alistair Cockburn proposed this interesting pattern. Quoting his words, the primary intent is:
Allow an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases.
As events arrive from the outside world at a port, a technology-specific adapter converts it into a usable procedure call or message and passes it to the application. The application is blissfully ignorant of the nature of the input device. When the application has something to send out, it sends it out through a port to an adapter, which creates the appropriate signals needed by the receiving technology (human or automated). The application has a semantically sound interaction with the adapters on all sides of it, without actually knowing the nature of the things on the other side of the adapters.
We could graphically represent this idea in this way:
According to this pattern, it is a good idea to design our applications with some separation between the application core, which contains the domain logic, and an outer layer of adapters through which our application interacts with the external components. Following this, Web API/MVC controllers would be good examples of adapters – they are responsible by to provide data and to handle inputs. The same applies to the repository pattern implementations which interacts with the database.
While some abstractions are useful in the domain model, they may not translate well to the message contract expected by the interacting applications. The outer layer, which contains the adapters implementations, is where we leave these abstractions and convert to the representation expected by the external components (database, user interface and so on).
A good example of this pattern implications would be the adoption of a separated model for persistence as the first option whenever necessary. Another example is the use of DTOs in the frontend.
To adopt this pattern reduces the coupling and makes the system easy to maintain. In the short term, that could increase the development costs. Anyway, this cost is easily justified in the long run.
