Clean Architecture – Interface Adapters
Today we will take a closer look at the Interface Adapter shell of Uncle Bob’s Clean Architecture.
In my first article on Clean Architecture, we learned about Business Logic but not much about Interface Adapters. Let’s do a quick recap on Business Logic and then dive into Interface Adapters.
Business Logic lives at the centre of our Clean Architecture universe. Everything inside the thin red circle is Business Logic—Entities and Use Cases. It’s what the system does, not how it does it—policy, not mechanism.
Programming the Business Logic is usually straightforward and should be even a bit boring. It simply deals with the aspects of business workflow that are entirely devoid of mechanism—i.e. no web, mobile, database, cache, external services, email, hardware, etc.. In our world of Clean Architecture and as specified by the Dependency Rule, Business Logic is entirely unaware of these things. It knows about them only through interfaces and other abstractions.
Business Logic communicates with the rest of the system via abstractions (i.e. interfaces) represented by the thin red line. These interfaces belong to the Business Logic. It’s these interfaces that make the system pluggable.
Beyond the red line live the Interface Adapters—here things get more interesting. This ‘shell’ connects the Business Logic to the mechanisms. It’s a conduit or channel layer that calls must pass through to make it to the mechanisms: web, database, external services, etc..
Below is a different depiction of the Interface Adapter shell. The adapters are the Interface Adapters from the Clean Architecture diagram.
All incoming calls from Business Logic get converted into a format that the mechanisms can understand.
For example, our Business Logic makes a call—against an interface—to save a Customer. Say, we have a SQL Server database implementation—an adapter—for that interface. When the adapter receives the call to update a Customer, it will convert the Customer model to a CustomerDb model suitable for persisting to the Customers table in our SQL Server database. This adapter will convert the incoming call into one or more appropriate calls to the database. If needed, it will open a database transaction too. And the same thing will happen when the call returns— another conversion will occur, but this time from SQL Server models back to business logic models.
In the Clean Architecture diagram, the Interface Adapters are depicted as a single schematic shell yet may represent multiple shells. Some systems might be fine with a single shell, while other, more sophisticated systems may require further layers. Reasons for multiple shells might be
- Consolidation of data from various data sources,
- Persisting data to multiple data sinks,
- Cascading data access (e.g. caching)
That’s it for today.
We will discover more about Interface Adapters next time.