---
title: 'Hexagonal Architecture: What You Need To Know - Simple Explanation'
source: 'https://youtube.com/watch?v=bDWApqAUjEI'
video_id: 'bDWApqAUjEI'
date: 2026-06-14
duration_sec: 496
---

# Hexagonal Architecture: What You Need To Know - Simple Explanation

> Source: [Hexagonal Architecture: What You Need To Know - Simple Explanation](https://youtube.com/watch?v=bDWApqAUjEI)

## Summary

Hexagonal architecture, also known as ports and adapters pattern, decouples an application's core logic from external systems like databases and APIs. It uses ports (interfaces) and adapters (implementations) to handle inputs and outputs, making the application more testable, maintainable, and flexible. However, it adds complexity and may not be suitable for small or simple projects.

### Key Points

- **Introduction to Hexagonal Architecture** [00:00] — The video explains hexagonal architecture, also called ports and adapters pattern, which decouples core logic from external systems.
- **Three-Tier Model Comparison** [00:12] — Traditional three-tier architecture (presentation, logic, data) can lead to tight coupling; hexagonal architecture takes decoupling further.
- **Ports and Adapters Pattern** [01:04] — Alistair Cockburn created hexagonal architecture, noting similarities between interacting with databases and external apps. Ports are abstractions (interfaces) defined by the application, adapters implement them for specific technologies.
- **Hexagon as a Visual Metaphor** [01:26] — The core logic is in the center, with ports on each side for inputs and outputs. The hexagon shape allows multiple sides for different interactions.
- **Adapters Convert Data** [02:31] — Adapters convert application output into formats suitable for external sources (e.g., database, file system). Changing adapters doesn't affect core logic.
- **Driving and Driven Sides** [03:10] — Inputs (driving side) trigger the application; outputs (driven side) are actions the application performs. Both use ports and adapters.
- **Why Hexagon?** [03:37] — No specific reason for hexagon; it's a convenient shape to represent multiple sides. Hexagons can connect like a honeycomb for complex applications.
- **Domain-Driven Design Connection** [04:28] — Large applications can be split into multiple hexagons, each responsible for one domain (e.g., user management, search), connected via ports and adapters.
- **Pros: Testability** [05:05] — Abstractions make unit testing easier because components can be tested in isolation without tight coupling.
- **Pros: Maintainability** [05:31] — Decoupling from underlying technologies allows easy swapping of databases or other systems by changing only the adapter.
- **Pros: Flexibility** [05:56] — Adapters can be changed to write to different data sources or other hexagons, enabling additional processing without affecting core logic.
- **Cons: Added Complexity** [06:19] — Introducing ports and adapters increases code volume and maintenance overhead.
- **Cons: Local Development Complexity** [06:36] — Running multiple isolated components locally can be challenging, similar to microservices.
- **Cons: Performance Overhead** [06:58] — Splitting into multiple hexagons communicating via APIs can introduce latency.
- **When to Use Hexagonal Architecture** [07:25] — Suitable for large applications with many inputs/outputs or mature apps needing technology changes. Not recommended for small or simple projects.

### Conclusion

Hexagonal architecture offers significant benefits in testability, maintainability, and flexibility but adds complexity. It's best suited for large or evolving applications where decoupling from external systems is valuable.

## Transcript

hey friends welcome back to the channel
So today we're going to be having a look
at hexagonal architecture now hopefully
by the end of this video you can
understand what it is how it works and
more importantly when you should be
using it if you've looked into software
architecture before you've probably
heard about the three-tier model this is
where your application is split into
three different layers the first layer
is the presentation layer this is the
layer that your users interact with so
this could be using a front end or
calling an API for example it's all
about how you present your data to your
users the second layout is the logic
layer which as the name suggests it's
where all the logic of your application
happens and lastly we have the data
layout which controls how all data is
persisted in your application the
three-tier model is a good place to
start if you're architecting an
application but it's very easy to make
each of the layers highly coupled to
each other we use things such as
dependency injection and Abstract
classes to prevent that coupling from
happening as we'll see with hexagonal
architecture it takes that decoupling to
a whole nother level as with all things
in software development and the English
language in general we do have a few
names for the same thing now if you
haven't heard of hexagonal architecture
before you may have heard of the ports
and adapters pattern Alistair cockburn
who came up with the idea for the
hexagonal architecture realized there
wasn't much difference between
interacting with a database and
interacting with external applications
they all follow a similar pattern in the
same way that we might use an interface
and a repository for interacting with
the database we can use ports and
adapters for all of the inputs and the
outputs of our application now imagine
that your application is a hexagon with
the middle of the hexagon making up the
core logic of your application now the
goal here is for every input and output
of your application we want to create a
port the port is really just an
abstraction it's a way for your
application to interact with the outside
world without knowing anything about
what it's interacting with it is
effectively a contract that your
application defines of how it wants to
interact with other systems let's say we
want to read and write from a database
instead of having your application call
the database directly you'd have a
separate read and write method your
application shouldn't actually care
where the data is coming from it could
be writing to a database or it could be
writing to the file system or even a
message queue as long as it has a way of
reading and writing data that's what is
important to your application so the
port is really just a custom interface
to your application that is defined by
your application now we do tend to use
interfaces in our code to create this
similar pattern but we tend to put too
much context into what that interface is
doing so we might have an idb repository
interface that allows you to write to a
database but your application shouldn't
care where it's writing it just needs an
interface with a read and a write method
now the next part of this pattern is the
adapter the adapter is where the core
logic happens for writing to a database
or to a file system or to anything else
for that matter it's essentially a
converter that takes the output of your
application and converts into something
that can be used by an external source
so in this example our adapter would
take the data from the port and convert
it into something that could be written
to a database the key thing is that no
matter what you change in your adapter
the application itself with its Port
never changes this is really useful
because it decouples the logic of your
application from the database and the
external sources and when you think
about it it's not just the outputs of
your application that can follow this
pattern the inputs can use it as well
there are lots of different ways that we
can interact with your application it
might be that we're using an API but
equally it could be triggered off a
message in a queue but in each case the
core logic of your application shouldn't
care what's triggered it the inputs
should just be the same each time so we
have two sides for our application we
have the input and the output and this
is something that Alistair describes as
the driving side and the driven side so
the input is driving our application to
do something whereas the output is
driven by the application itself so
we've talked a lot about hexagons but
why is it called hexagonal architecture
and not Circle architecture or triangle
architecture from what I've read there's
no clear reason of why it's a hexagon
and not another shape it's just a case
that's a nice shape where you can put
sides to show the inputs and outputs but
what do you think about when you think
of a hexagon for me I think about a
honeycomb in a beehive with lots and
lots of hexagons connected together now
clearly your application can have
multiple inputs and outputs and one of
those inputs might be an API now
generally we think of outputs as writing
to a file system or to a database
however if you've ever worked with Cloud
platforms like AWS you'll know that when
you write to a database such as dynamodb
you're actually just calling the AWS API
so if your inputs or apis and your
outputs or apis you can start to imagine
how all of these hexagons could connect
together into a giant honeycomb
application if you have a particularly
large application you could start
splitting it up into different hex guns
this is the concept behind domain driven
design in this case each of your
hexagons is only responsible for one
domain so one of the domains might be
user management for example and you
might have another hexagon that's in
charge of search and another one that's
in charge of file persistence and maybe
you might have another one that sends
emails each of these head skins can
therefore be independent working units
with a single responsibility and then
you can use ports and adapters to
connect them all together now before you
go ahead and spend the next six months
rewriting your application in this way
we need to understand the pros and cons
of hexagonal architecture now one of the
main Pros for hexagonal architecture is
testability if you've ever tried to
write unit tests for an application when
testing wasn't thought up you'll know
how difficult it is when a component is
tightly coupled to other components it
can be very difficult if not impossible
to test it in isolation of course with
hexagonal architecture this isn't going
to be an issue because everything is
going to be using abstractions by Design
which makes it a lot easier to test the
next Pro is maintainability as your
application is completely decoupled from
the technologies that are underlying it
it becomes a lot easier to change those
Technologies when you need to let's say
that your database that you picked
originally isn't scaling the way you
wanted it to and you want to use
something like dynamodb in this case all
you need to do is switch out the adapter
so the rights to dynamodb instead of a
database but the core logic of your app
education doesn't need to change and the
last positive that I can think of is
around flexibility as with
maintainability you can quickly change
things in your application but it
doesn't actually have to be the
technology that changes in the same way
that you can change an adapter so that
it's writing to a different data source
you can also change the adapter so it's
writing to a different hexagon and
therefore you can add in things like
additional data processing without
affecting the core logic of your
application so they're the main
positives what about the negatives of
hexagonal architecture so one of the
main cons it adds in a lot of complexity
into your code instead of just writing
directly to the database we're going to
have to introduce ports and adapters to
be able to do that and therefore you're
adding more code to your application and
every line of code is effectively a
liability it's something you need to
maintain going forward the second con is
the complexity it takes to run your
application on your local machine if
your application is made up of multiple
components each running in isolation it
can be quite difficult to get everything
running up locally on your machine so
that you can do your development anyone
who has worked with microservices will
know the pain of having to run up 20
different Docker containers just to be
able to get the application running on
your machine the last con that you need
to think about is the performance of
your application if you split your
application up into lots of different
hexagons and have each of them
interacting over an API then you could
end up introducing a lot of latency into
your application that wasn't there
before so you need to be mindful of
which components you spit out whether
that's going to add any performance
issues to your application now hopefully
now you have a better understanding of
what hexagon architecture is and how it
works if you've liked this video so far
please hit the like button it really
helps with the YouTube algorithm now the
last thing we're going to look at is
should you use hexagon architecture in
your project as with all things it
depends it depends on the size of your
application and maturity if your
application is particularly large with a
lot of inputs and outputs then it makes
sense that you might want to decouple
that from some of the technologies that
you're using however if your application
is particularly small then it's probably
not worth the effort if your application
is a particularly mature application
that you've been working on for several
years and it's not already using
hexagonal architecture then you might
need to look into it technology has
changed all the time and if your
application is going to be staying
around for a while then you're probably
going to need to change the underlying
Technologies from time to time so the
next time you have to add in a new input
method or change one of the underlying
Technologies you might want to look into
hexagonal architecture to make your
application easier to maintain thank you
for watching don't forget to hit
subscribe and I will see you in the next
video