How Adapters Enable Pluggable Architecture

Adapters play a central role in Software Architecture.

So far, we’ve learned about The Adapter Pattern and how adapters can help us overcome integration problems.

Today we’ll discover how adapters allow us to create pluggable architecture in our software.

What do we mean by pluggable architecture?

A pluggable architecture is one in which we can swap out specific sub-systems for similar but different sub-systems. 

For example, in a well-architected system, we should be able to unplug a SQL Server database implementation and replace it with another database, say, Mongo DB. With relatively little effort, that is, not months of hard work untangling SQL Server data access code.

A picture will help. Here is what a pluggable architecture looks like:

Our application business logic sits at the top. The direction of control flows from the business logic down to specific services. Business logic represents the part of the system that directs WHAT happens (e.g. save some data), not HOW it happens (e.g. write to Mongo DB database). 

Business logic requires several services: Access to persisted data (e.g. database), the ability to notify people of application activity, and so on.

Rather than the business logic itself recognising the exact nature of these services, it only knows about abstractions of them—here represented by the Repository Interface and the Notifier Interface.

As we know, adapters bridge the gap between two interfaces, the one provided by business logic and the one exposed by the specific technical implementation, i.e. the mechanism.

For example, business logic uses the Notifier Interface for sending notifications. As it stands, the notification technology to be used is, say, email, specifically AWS Simple Email Service (SES). To make this work, we need a connector that implements the Notifier Interface and makes it work with the AWS SES SDK library. That is the purpose of the AWS Emailer Adapter.

Pluggability gives us options. 

We could easily switch from AWS SES to SMTP emailing by writing an SMTP Emailer Adapter. This adapter will also implement the Notifier Interface. However, its second interface implementation will make calls to an email library to send emails via SMTP. Or we could send notifications as SMS/texts by writing an appropriate adapter and SMS sending mechanism. The ball’s in our court—how do we want to send notification messages?

Similarly, we could replace the Mongo DB mechanism in our example pluggable architecture with SQL Server by writing a suitable adapter that implements the Repository Interface and the interface to a SQL Server library.

Adapters are a crucial part of making a pluggable architecture work. They bridge the gap between the general interface use by business logic and the interface exposed by the chosen technology.