Abstracting External Systems in Hexagonal Architecture
Discover the domain model refinement and abstraction within hexagonal architecture, which allows seamless interaction with external systems, enhancing testability and flexibility in application development.
In this lesson, we’ll consider some of the decisions we need to make when applying hexagonal architecture approach. We’ll take a step-by-step approach to handling external systems where we’ll first decide what the domain model needs, and then work out the right abstractions that hide their technical details.
We’ll consider two common external systems:
Web requests
Database access
Creating abstractions for external systems
The place to begin our design is with our domain model. We need to devise a suitable port for our domain model to interact with. This port has to be free from any details of our external system, and at the same time, it must answer the question of what our application needs this system for. We’re creating an abstraction.
A good way to think about abstractions is to consider what would stay the same if we changed how we performed a task. Suppose we want to eat warm soup for lunch. We might warm it in a pan on the stove or perhaps in the microwave. No matter how we choose to do it, what we are doing stays the same. We are warming the soup, and that is the abstraction we’re looking for.
We don’t often warm soup in software systems unless we’re building an automated soup vending machine. However, there are several common kinds of abstractions we’ll be using. This is because common kinds of external systems are used when building a typical web application. The first and most obvious is the connection to the web itself. In most applications, we’ll encounter some kind of data store, typically a third-party database system. For many applications, we’ll also be calling out to another web service. In turn, this service may call others in a fleet of services, all internal to our company. Another typical web service call is to a third-party web service provider, such as a credit card payment processor, as an example.
Abstract common external systems
Let’s look at ways of abstracting these common external systems.
Abstracting web requests and responses
Our application will respond to HTTP requests and responses. The port we need to design represents the request and the response in terms of our domain model, stripping away the web technology.
Our sales report example could introduce these ideas as two simple domain objects. These requests can be represented by a RequestSalesReport class:
Get hands-on with 1400+ tech skills courses.