Hexagonal Architecture: What You Need To Know - Simple Explanation

[00:00] hey friends welcome back to the channel

[00:01] So today we're going to be having a look

[00:03] at hexagonal architecture now hopefully

[00:05] by the end of this video you can

[00:06] understand what it is how it works and

[00:09] more importantly when you should be

[00:10] using it if you've looked into software

[00:12] architecture before you've probably

[00:13] heard about the three-tier model this is

[00:15] where your application is split into

[00:16] three different layers the first layer

[00:19] is the presentation layer this is the

[00:20] layer that your users interact with so

[00:22] this could be using a front end or

[00:24] calling an API for example it's all

[00:26] about how you present your data to your

[00:28] users the second layout is the logic

[00:30] layer which as the name suggests it's

[00:31] where all the logic of your application

[00:33] happens and lastly we have the data

[00:35] layout which controls how all data is

[00:37] persisted in your application the

[00:39] three-tier model is a good place to

[00:41] start if you're architecting an

[00:42] application but it's very easy to make

[00:44] each of the layers highly coupled to

[00:45] each other we use things such as

[00:47] dependency injection and Abstract

[00:49] classes to prevent that coupling from

[00:51] happening as we'll see with hexagonal

[00:53] architecture it takes that decoupling to

[00:55] a whole nother level as with all things

[00:57] in software development and the English

[00:58] language in general we do have a few

[01:00] names for the same thing now if you

[01:02] haven't heard of hexagonal architecture

[01:04] before you may have heard of the ports

[01:05] and adapters pattern Alistair cockburn

[01:07] who came up with the idea for the

[01:09] hexagonal architecture realized there

[01:11] wasn't much difference between

[01:12] interacting with a database and

[01:14] interacting with external applications

[01:15] they all follow a similar pattern in the

[01:18] same way that we might use an interface

[01:19] and a repository for interacting with

[01:21] the database we can use ports and

[01:23] adapters for all of the inputs and the

[01:24] outputs of our application now imagine

[01:26] that your application is a hexagon with

[01:28] the middle of the hexagon making up the

[01:30] core logic of your application now the

[01:32] goal here is for every input and output

[01:34] of your application we want to create a

[01:35] port the port is really just an

[01:37] abstraction it's a way for your

[01:39] application to interact with the outside

[01:40] world without knowing anything about

[01:43] what it's interacting with it is

[01:44] effectively a contract that your

[01:46] application defines of how it wants to

[01:48] interact with other systems let's say we

[01:50] want to read and write from a database

[01:51] instead of having your application call

[01:53] the database directly you'd have a

[01:55] separate read and write method your

[01:57] application shouldn't actually care

[01:58] where the data is coming from it could

[02:00] be writing to a database or it could be

[02:02] writing to the file system or even a

[02:04] message queue as long as it has a way of

[02:05] reading and writing data that's what is

[02:07] important to your application so the

[02:09] port is really just a custom interface

[02:11] to your application that is defined by

[02:13] your application now we do tend to use

[02:15] interfaces in our code to create this

[02:16] similar pattern but we tend to put too

[02:18] much context into what that interface is

[02:20] doing so we might have an idb repository

[02:23] interface that allows you to write to a

[02:25] database but your application shouldn't

[02:27] care where it's writing it just needs an

[02:29] interface with a read and a write method

[02:31] now the next part of this pattern is the

[02:33] adapter the adapter is where the core

[02:34] logic happens for writing to a database

[02:37] or to a file system or to anything else

[02:39] for that matter it's essentially a

[02:40] converter that takes the output of your

[02:42] application and converts into something

[02:44] that can be used by an external source

[02:45] so in this example our adapter would

[02:48] take the data from the port and convert

[02:50] it into something that could be written

[02:52] to a database the key thing is that no

[02:54] matter what you change in your adapter

[02:55] the application itself with its Port

[02:58] never changes this is really useful

[03:00] because it decouples the logic of your

[03:02] application from the database and the

[03:04] external sources and when you think

[03:05] about it it's not just the outputs of

[03:07] your application that can follow this

[03:08] pattern the inputs can use it as well

[03:10] there are lots of different ways that we

[03:12] can interact with your application it

[03:14] might be that we're using an API but

[03:15] equally it could be triggered off a

[03:17] message in a queue but in each case the

[03:19] core logic of your application shouldn't

[03:21] care what's triggered it the inputs

[03:22] should just be the same each time so we

[03:24] have two sides for our application we

[03:26] have the input and the output and this

[03:27] is something that Alistair describes as

[03:29] the driving side and the driven side so

[03:31] the input is driving our application to

[03:34] do something whereas the output is

[03:35] driven by the application itself so

[03:37] we've talked a lot about hexagons but

[03:39] why is it called hexagonal architecture

[03:40] and not Circle architecture or triangle

[03:43] architecture from what I've read there's

[03:44] no clear reason of why it's a hexagon

[03:46] and not another shape it's just a case

[03:48] that's a nice shape where you can put

[03:50] sides to show the inputs and outputs but

[03:52] what do you think about when you think

[03:54] of a hexagon for me I think about a

[03:56] honeycomb in a beehive with lots and

[03:58] lots of hexagons connected together now

[04:00] clearly your application can have

[04:02] multiple inputs and outputs and one of

[04:04] those inputs might be an API now

[04:06] generally we think of outputs as writing

[04:09] to a file system or to a database

[04:10] however if you've ever worked with Cloud

[04:12] platforms like AWS you'll know that when

[04:15] you write to a database such as dynamodb

[04:17] you're actually just calling the AWS API

[04:20] so if your inputs or apis and your

[04:22] outputs or apis you can start to imagine

[04:24] how all of these hexagons could connect

[04:26] together into a giant honeycomb

[04:28] application if you have a particularly

[04:30] large application you could start

[04:32] splitting it up into different hex guns

[04:34] this is the concept behind domain driven

[04:36] design in this case each of your

[04:37] hexagons is only responsible for one

[04:39] domain so one of the domains might be

[04:41] user management for example and you

[04:43] might have another hexagon that's in

[04:45] charge of search and another one that's

[04:46] in charge of file persistence and maybe

[04:49] you might have another one that sends

[04:50] emails each of these head skins can

[04:52] therefore be independent working units

[04:54] with a single responsibility and then

[04:56] you can use ports and adapters to

[04:58] connect them all together now before you

[04:59] go ahead and spend the next six months

[05:01] rewriting your application in this way

[05:03] we need to understand the pros and cons

[05:05] of hexagonal architecture now one of the

[05:07] main Pros for hexagonal architecture is

[05:08] testability if you've ever tried to

[05:10] write unit tests for an application when

[05:12] testing wasn't thought up you'll know

[05:14] how difficult it is when a component is

[05:16] tightly coupled to other components it

[05:18] can be very difficult if not impossible

[05:20] to test it in isolation of course with

[05:22] hexagonal architecture this isn't going

[05:23] to be an issue because everything is

[05:25] going to be using abstractions by Design

[05:27] which makes it a lot easier to test the

[05:29] next Pro is maintainability as your

[05:31] application is completely decoupled from

[05:33] the technologies that are underlying it

[05:34] it becomes a lot easier to change those

[05:37] Technologies when you need to let's say

[05:39] that your database that you picked

[05:41] originally isn't scaling the way you

[05:43] wanted it to and you want to use

[05:44] something like dynamodb in this case all

[05:46] you need to do is switch out the adapter

[05:48] so the rights to dynamodb instead of a

[05:50] database but the core logic of your app

[05:52] education doesn't need to change and the

[05:54] last positive that I can think of is

[05:56] around flexibility as with

[05:58] maintainability you can quickly change

[05:59] things in your application but it

[06:01] doesn't actually have to be the

[06:02] technology that changes in the same way

[06:04] that you can change an adapter so that

[06:06] it's writing to a different data source

[06:08] you can also change the adapter so it's

[06:10] writing to a different hexagon and

[06:12] therefore you can add in things like

[06:13] additional data processing without

[06:15] affecting the core logic of your

[06:16] application so they're the main

[06:18] positives what about the negatives of

[06:19] hexagonal architecture so one of the

[06:21] main cons it adds in a lot of complexity

[06:23] into your code instead of just writing

[06:25] directly to the database we're going to

[06:26] have to introduce ports and adapters to

[06:28] be able to do that and therefore you're

[06:29] adding more code to your application and

[06:31] every line of code is effectively a

[06:33] liability it's something you need to

[06:34] maintain going forward the second con is

[06:36] the complexity it takes to run your

[06:38] application on your local machine if

[06:40] your application is made up of multiple

[06:42] components each running in isolation it

[06:44] can be quite difficult to get everything

[06:46] running up locally on your machine so

[06:48] that you can do your development anyone

[06:49] who has worked with microservices will

[06:51] know the pain of having to run up 20

[06:53] different Docker containers just to be

[06:55] able to get the application running on

[06:56] your machine the last con that you need

[06:58] to think about is the performance of

[06:59] your application if you split your

[07:01] application up into lots of different

[07:02] hexagons and have each of them

[07:04] interacting over an API then you could

[07:06] end up introducing a lot of latency into

[07:08] your application that wasn't there

[07:09] before so you need to be mindful of

[07:11] which components you spit out whether

[07:12] that's going to add any performance

[07:14] issues to your application now hopefully

[07:16] now you have a better understanding of

[07:17] what hexagon architecture is and how it

[07:19] works if you've liked this video so far

[07:21] please hit the like button it really

[07:23] helps with the YouTube algorithm now the

[07:25] last thing we're going to look at is

[07:26] should you use hexagon architecture in

[07:28] your project as with all things it

[07:29] depends it depends on the size of your

[07:31] application and maturity if your

[07:33] application is particularly large with a

[07:34] lot of inputs and outputs then it makes

[07:37] sense that you might want to decouple

[07:38] that from some of the technologies that

[07:40] you're using however if your application

[07:41] is particularly small then it's probably

[07:43] not worth the effort if your application

[07:45] is a particularly mature application

[07:46] that you've been working on for several

[07:48] years and it's not already using

[07:49] hexagonal architecture then you might

[07:51] need to look into it technology has

[07:53] changed all the time and if your

[07:54] application is going to be staying

[07:55] around for a while then you're probably

[07:57] going to need to change the underlying

[07:58] Technologies from time to time so the

[08:00] next time you have to add in a new input

[08:02] method or change one of the underlying

[08:04] Technologies you might want to look into

[08:05] hexagonal architecture to make your

[08:07] application easier to maintain thank you

[08:09] for watching don't forget to hit

[08:10] subscribe and I will see you in the next

[08:12] video