Hexagonal Architecture

Hexagonal Architecture



Hi My name is Marcus Biel, I'm a software
craftsman with fourteen years of experience in
Java development. Today I would like to talk about hexagonal architecture. This talk is actually based on a talk from Chris Fidao, a PHP developer and also influenced a bit by a talk from Robert C Martin. I have the links to both talks in the references
at the end of the talk. Okay let's start. First of all let's talk about the motivation for the
hexagonal architecture. We try to improve the
maintainability with hexagonal architecture because it
is very important that we can do easy changes and that we can change this software very fast the faster we can make changes, of course the
less time it needs us and so or system can be developed faster and cheaper. Uhm so more the technical dept increases the lower is our maintainability and hexagonal architecture want's to improve that with the use of
layers just as well as many other architectures. Okay so now let's have a look. Here we see
the hexagon The hexagonal architecture as you might guess is called hexagonal
architecture because of this image here the hexagon. So the hexagon is a symbol with six sites as you see here and they represent actually six different ways of communicating with the system. As of today you actually can communicate n-times so any number of times with the system but this is how hexagonal architecture
was named hexagonal architecture anyway. So we have different layers I said, here you
can see framework, application and domain. Chris Fidao even speaks of core domain but for me it's
both the same so I just used domain. Actually hexagonal architecture is a perfect fit for domain
driven design So if you know what domain
driven design is, perfect. So you would use domain driven design here in the red layer, in the domain; but if you don't
know domain driven design it doesn't matter you can use hexagonal
architecture even without domain driven design just know that they're both a perfect fit. So okay so we have these layers and now let's go through each of them. But anyway, first of all let's have a look
at the outside. So our system would remotely communicate
with any number of remote systems in any kind of format, like rest, http, binary
soap, sql, or it could also communicate with
other hexagonal systems, for example especially if you have a big system, you can actually split your system up
into different hexagonal architectures that communicate
remotely which is a great way of enabling greater teams to split up and to parallely work on different parts of the
system Okay. now framework. This is the first layer of our hexagonal architecture. The framework
layer is called framework layer because this is
the place were usually the framework would
sit if you use a framework. I mean you don't need to use a framework, this is
totally up to you so to phrase it differently, this is the place where the
communication coming from outside as you saw before, here, so this is the
place that transfers the incoming stream to an object that we can
work on. In the case of html for example http
communication for example you could have a
controller here that would than provide a request and response object that you could work on.
So let's have a look at an example. Here. This is an example written in Java. So you could have an http controller extending some kind of a base controller not necessarily, but here this is just my
example you would have a process method that would receive request and response actually I meant http request and http
response. but so that it fits on the slide I just
wrote request and response. And so we would retrieve parameters taken from the
request would wrap them in a command. A command is actually a pattern from the Gang of Four a design pattern. I hope you know it, if not maybe just look it up on the web. So we wrap parameters in a command and then we forward this command to a command bus so what is a command bus actually? Let's have a look. The command bus is in the application layer. And the application layer as you can see
here sits right in the middle between domain
and framework so what is inside the application
layer besides the command bus which I actually already mentioned. So the application
layer contains everything that is not specific
to a certain technology anymore. So it's not specific
to http not specific to rest, soap and so on but it's also not domain-specific yet. so it's like a man in the middle layer
you could say Okay. now let's have a look here we see the comand bus and we have a execute method that takes the command that before in the controller we created
and this command gets forwarded to its specific handler. so for each comand we would have
specific handler A command could be for example addUser so it's an abstract form of something that needs to
get done a use case and for this example for a AddUserCommand. We would have a AddUserHandler.
Now you need some kind of a strategy to find out which handler is going to handle which command. In my case I used a registry which is another design pattern but you could also do it in any other simple way like using reflection and then just when
the command is called AddUser you could have a String replace and than have a handler AddUser Handler and forward to this handler and then we call the execute method on the
handler Okay, so next layer is the domain layer so the domain layer contains all the domain logic and also constraints. What is a constraint? Constraint here is represented by
the InvalidGearException. So everything the domain is not able to do. So in this example here I have a class car that provides a method drive and if the domain logic says you're not allowed to drive with that gear
an InvalidGearException is thrown. And this exception will bubble up all
the way up to the top into the framework were it's handled once. Handled for example could mean that it's logged and then
forwarded in a specific format for example in soap would be a soap fault in rest it could
just be a rest message indicating the error to the client okay, so actually hexagonal architecture is also called
ports and adapters. So why is it called ports and adapters? ports and adapters. So we have ports and the adapters are perfectly fitting into
those ports. The ports are like the sides of our
hexagon. So the ports are the different technical formats that our system supports and the adapters are like each layer is an adapter for the layer around it you could say or you could also phrase it as an adpater is the implementation and a port is an interface because something very
important about hexagonal architecture is its interfaces because with the interfaces we encapsulate the system, no we don't encapsulate it but we have it maintainable so that each layer is separated by itself. Okay. So now, I already talked shortly about use cases
a command like MakeCall, ReceiveCall, SendSms I mean a use case in our hexagonal
architecture is presented as a use case and the good thing about this is you
implement your command, your use case once and then you're totally
agnostic of the specific technical implementation
one team can focus and can design on the use cases without
the system being actually finished while another team can already start implementing the technical ports that are coming into the system
independent of a specific use case Okay. So here again we see the hexagon and the
different layers so I already talked about interfaces and how interfaces are
important for our hexagonal architecture actually each layer protects itself with a boundary from the outer layer around it Yeah. So here this is also something I have kind of taken from Chris Fidao we see the Chinese Wall I think the Chinese Wall is a very nice example
of a boundary. It protected the Chinese for
hundreds of years and this is the same idea in our
hexagonal architecture that each layer is protected from the
layer around it so the dependencies are coming from outside in. So the domain is independent of the application and
the application is independent of the framework. So how do
we achieve that actually? We achieve that with inversion of control or dependency
injection which you probably have heard of already so in c# as well as in java for example you have dependency injection for example with anotations or with
the help of in spring you can also define an XML context file that sets up your
dependency injection however this is a bit problematic because then again your system is not independent from, I mean the different
classes the different beans that you set up are not
independent of each other or at least they are dependent on the
framework in this case spring and they should not
be. So I don't know about C# but I do know about Spring in version 4 of Spring it's possible to set up context classes and then, really your different services and classes you set up don't contain any code and neither any
annotations and so they're totally agnostic of any
framework in the domain which is really great and
the way it should be. Okay so I said before in hexagonal architecture we do need
interfaces interfaces are really a big thing in hexagonal architecture. This is the way we stay independent so that each layers is independent of the next one so this is the interface for CommandBus that takes a Command and this another example is the interface for the
CommandHandler Okay. We are almost done, I have two sentences that I want to cite from Robert C. Martin
that I really liked. a good architecture maximizes the number of decisions not made. Think about it. Because this really keeps us flexible and a good
architecture allows major decisions to be deferred, because the best
decisions are the ones that are done as late as
possible because only than you have all the
information available so this is how interfaces help us with the use of interfaces defer
the decision latest possible time. Okay. last but not least the references. So the first one is as I already mentioned a talk from Chris Fidao, really great stuff, you should really look it up, he has put up all his slides you can see his presentation on youtube
and he has a huge site it's actually a bit hidden but if you
scroll down on this link there's heaps of information about hexagonal
architecture and second a talk from Robert C. Martin about what he calls clean
architecture and design but it's really much related to
hexagonal architecture I would say. Okay. These slides you can find on marcus-biel.com/ HexagonalArchitecture.pptx Okay. Thank you!


6 thoughts on “Hexagonal Architecture

  1. This is great! Thanks for sharing – Would you consider putting the links from the slide into the description? It would make it a lot easier for the audience.

  2. This talk actually based on a talk from Chris Fidao, a PHP developer, and also influenced a bit by a talk from Robert C Martin.
    Hexagonal architecture maintainabilityFirst of all let’s talk about the motivation for the hexagonal architecture.
    Hexagonal architectureWe try to improve the maintainability with hexagonal architecture because it is very important that we can do easy changes and that we can change this software very fast. The faster we can make changes, of course the less time it needs us and so or system can be developed faster and cheaper. The more the technical dept increases the lower is our maintainability and hexagonal architecture want’s to improve that with the use of layers, just as well as many other architectures. Okay so now let’s have a look. Here we see the hexagon. The hexagonal architecture, as you might guess is called hexagonal architecture because of this image here, the hexagon…

Leave a Reply

Your email address will not be published. Required fields are marked *