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