---
title: Ready for changes with Hexagonal Architecture - my notes
disqus: pierodibello
---

###### tags: `architecture` `hexagonal`

_(notes taken from [Ready for changes with Hexagonal Architecture](https://netflixtechblog.com/ready-for-changes-with-hexagonal-architecture-b315ec967749))_

# Hexagonal Architecture

puts inputs and outputs at the edges of the domain

- swappable data sources
- ability to easily swap data sources without impacting business logic and need to rewrite the codebase
- easily testable in isolation


Elements:

* **entities** - core domain objects
* **repositories** - contains all the entitites and create / change them (interfaces for the actual adapters / data sources)
* **interactors** (aka *Service Objects* or *Use Case Objects*) - orchestrate the domain objects to perform domain actions

How business logic is triggered?

* **transport layer** - triggers an interactor to perform business logic. Inputs for the system. ("Inbound ports"). The most common transport layer is the HTTP API Layer
* **data sources** - adapters to different storage implementations. ("Outbound ports"). A data source implements methods defined on the repository for fetching and pushing the data.

### Testing strategy

have a test suite that is reliable and super fast

3 kind of tests:
* **test of interactors** ("unit" tests) - where the core of our business logic lives but is independent of any type of persistence or transportation => tests with mock instead of the real data sources, and without the transport layer (which is a layer above the interactors BTW)
* this is where our business logic is tested in detail, and these are the tests we strive to have most of.

* **test of data sources** (integration tests) - to determine if they integrate correctly with other services, whether they conform to the repository interface, and check how they behave upon errors.
* we try to minimize the amount of these tests.

* **integration specs** (end-to-end tests) - go through the whole stack, from our **transport** / API layer, through the **interactors**, **repositories**, **data sources**, and hit downstream services.
* to test if we "wired" everything correctly
* no extensive test coverage on this layer -> usually just one success scenario and one failure scenario per domain action