Change is the one thing all programmers have to face in their work lives. We make changes every day, codes move very fast to unknown destinations, and frequently one system change can break elements in a different system.
For example, is it possible to change the shape of our domain without breaking the modules that rely on it? And in a code, can we change a mapper to make a module work without modifications even if we completely change our domain model?
The answer to these questions is “yes”, it is possible, thanks to hexagonal architecture.
Hexagonal Architecture, also known as “Ports and Adapters Pattern”, is an architectural pattern exposed by Alistair Cockburn which applies the Anti-corruption Layer DDD Pattern in a very effective way. The concept is very simple: the domain model communicates with the external world using interfaces as ports. Every external module that wants to communicate with the domain builds an adapter and attaches it to the port.
What is an external module? It’s a database, it’s a REST API, it’s a mail sender, it’s a queue, it’s everything that is not part of our core domain. We can separate them into two types: driving and driven. The driving modules are the ones for which we expose functionalities (ex: REST APIs, queue to expose events) the driven are the ones used to perform actions (ex: database to persist data, mail sender, queue to receive events). An anti-corruption layer must be inserted between these systems and our core domain in order to keep our business logic decoupled from external logic and make sure that the internal domain and external entities do not depend on each other. Separating objects in the adapters will make it easier to map the domain’s internal representation into the external world’s objects.
Hexagonal architecture will decouple your business logic from the outside world. It makes it possible to change internal representation without breaking interactions with external modules and makes it possible to change technology or add new modules that will not affect your internal representation.
Here are 4 advantages of working with hexagonal architecture:
- Delaying decisions about technologies
Hexagonal architecture makes it possible to decide to start writing a project and actually build and test it while postponing technology decisions that would involve knowledge and data that may not be available at the beginning of a project. - Changing technology with a lower impact
Thanks to hexagonal architecture, tech companies can decide to start with the simplest technology (like the classic relational database) and then switch to another by simply changing the adapter. - Test business logic in isolation from external systems
Thanks to interfaces, it is possible to build stub or mock to test your core domain and your business logic isolated from external systems. This will confirm that any change in technology will not impact the business logic. - Reshape your internal domain with less effort on external systems
At a certain point, the internal domain will evolve. If the tech team’s been able to successfully decouple and keep on external adapters only the subset of data they need, this should come with a lower price and less effort.
However, the only drawback is that this kind of separation will cost the tech team more effort when building interfaces and mapping different domains.
Is hexagonal architecture really useful? The power of decoupling is often underestimated. Think about this scenario: tomorrow a new disruptive technology that crashes out old relational databases will arrive. With hexagonal architecture in place the tech team just needs to rewrite their db adapter without touching domain objects or the business logic. Without it, a series of problems and unexpected circumstances could arise, which could introduce regressions in the code.
Decoupling comes with a price, like insurance against future changes. The cost of changing a project with hexagonal architecture will be incomparably lower than the cost needed to adapt a domain against too many technology modifications.
Hexagonal architecture isn’t useful for projects that are guaranteed never to change – in which case paying a price for decoupling is a waste – but seriously, do any of us know of projects that aren’t bound to change at some point?
