You can find the code here https://github.com/lucaskatayama/learn-hexagonal
I am not going to do the step-by-step here. My goal is to analyze the pros and cons for this architecture.
To visualize:
flowchart LR
DB[(Postgres)]
dbcas[(Cassandra)]
subgraph UI
subgraph REST
Handlers
end
subgraph CLI
CMD
end
subgraph gRPC
RPC
end
end
subgraph Core
Service --> DBPort((DBPort))
end
subgraph Infra
subgraph Postgres
DBPort -.-> PostgresAdapter
end
subgraph Cassandra
DBPort -.-> CassandraAdapter
end
subgraph Mock
DBPort -.-> MockAdapter
end
end
PostgresAdapter --> DB
CassandraAdapter --> dbcas
Handlers --> Service
CMD --> Service
RPC --> Service
And from the post (https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/):
- The UI represents the Primary/Driver adapters
- The Core represents the Application and Domain layers
- The Infrastructure represents the Secondary/Driven adapters
The project
The result poject with an Hexagonal Architecture code is here https://github.com/lucaskatayama/learn-hexagonal under go folder.
The XP
The architecture is really simple to understand e implement. A little bit verbose and many times you will end up with methods with no or almost no logic.
But the pros when you get a large application can be helpful.
- If you need to change the Infrastructure (e.g change the database from MySQL to Postgres), it is going to be easier.
- The structure helps you spot problems faster.
- It can be done in other languages, it is NOT specific to Golang.
- It facilitates testing. You can mock infrastructure using a
MockAdapterimplementation. (check the mock folders) - It satisfies the backing services from 12Factor Apps.