A zoom on the hexagonal/clean/onion architecture

Several weeks from now, I've conducted an important study that was related to the middlewares we were using in the entire pre-trade perimeter of the bank I'm working for. One of the analysis criteria was the dependency & the coupling towards the used messaging technologies for every application. Even if there were lots of legacy applications involved in this study, I was still surprised to see how strong the coupling was and how far the various messaging technologies were spread within a huge number of applications (with messaging data structures present in the core business layers in the worst cases). The consequence of that?!? Some very costly (and risky) situations for those applications when we need to replace a former messaging technology they were using, by a better (and less risky) one.

This is where I realized that It was the time for me to communicate more on the strengths and the benefits of the hexagonal architecture, which I also recently successfully foster for another project (just before the middleware study).

Apart from being a new buzzword, what's the hexagonal architecture concretely?

Also known as 'Ports and Adapters', or clean, or onion architecture (other variants I won't detail here), the hexagonal architecture is an applicative-architecture-style that helps us to focus on our business goals without being tied or jeopardized by our technical frameworks or infrastructure choices. 

In that model there is no such thing as 'front-end' (users interactions) or 'back-end' (db) anymore, but two primary areas instead: the inside (with applicative-use-case-handlers and business domain code) and the outside (with all our infrastructure code: db access, messaging & communication bindings, etc). If you now combine this model with the dependency inversion principle which states that High-level modules should not depend on low-level modules. Both should depend on abstractions, you can easily infer that this model dictates that you can only point inwards the hexagon / circle (infrastructure being the low-level stuffs in that context).

Interactions between those two areas (in and out) are achieved by ports and adapters (P/A in the diagram below). In a nutshell, events or clients requests arrive from the outside world at a port (i.e. a plug for a technology), and the technology-specific adapter converts it into a usable procedure call or message and passes it to the application layer.

Ok, it's all about focusing on the real topics after all, right?

Indeed, an important point with the hexagonal architecture is that we put all our frameworks, drivers and infrastructure related code to the periphery of your system. Because those should be only details for our applications. Nothing more!

Strengths and benefits of the hexagonal architecture (to impress your world during geeks meetings)

• Sustainability / Timelessness: by decoupling our application-business code from the tools we are using (i.e. the libraries and frameworks), we make it less vulnerable to the erosion of time and IT fads
• Testability: The usage of ports and adapters to communicate with all our infrastructure (e.g. db, messaging systems, etc) eases the usage of mocks in order to test our applicative services and domain code. Tests could even be written for our application service layer before we decide which technology to be plugged with its corresponding port/adapter (whether REST, SOAP, specific messaging, db, etc)
• Adaptability / Time to market: adding a new way to interact with your application is very easy: you just add a new port/adapter to support this new technology and that's it! You can usually have multiple ways or technologies to interact with your application
• Understandability: Rather than having a solution where use cases are completely lost or mixed within all the technical stuff, this architecture style states the emergence of an applicative-use-case-layer (with all your use case handlers in a dedicated module). The proper location to make scream our functional intentions
• Use case driven & DDD compliance:  Indeed, with this architecture style, we design our applications with our use cases in mind; not the number of persistence technologies or binding types we will need to support! A typical project may start without deciding what kind of database it needs for his persistency, and pick the proper technology based on real data manipulated and usages discovered after several iterations (what we've done in a project recently; even if it took me some efforts to explain to the project manager that I was suggesting that strategy on purpose, and not by lazyness ;-) Cause you remember? a pragmatic architect usually defer decisions about the choice of frameworks or tools to be used.

OMG: is the hexagonal architecture a silver bullet?!?

Calm down. Please... This is not the Xmas architecture, and there is still no such things as Silver bullet ;-) But as Vaughn Vernon says in his Implementing Domain Driven Design book (iDDD) : 

'The hexagonal architecture forms the strong fundation for supporting any and all those additional architectural options' (i.e. SOA, REST, event-driven, event-sourcing, CQRS, etc)

I don't understand a word of this post. May I read other stuff on this topic in real & solid english?

Sure. Even if it's not very gentle for me... Anyway, if you want to dig a little bit on that matter, I highly recommend you the reading (of at least the chapter 4) of the iDDD book. You can also read the original pattern description by Alistair Cockburn, or the more recent explanations by Robert C Martin about the clean architecture (here as post, or here in this fabulous video session). By the way, I have no doubt that the next book of Uncle Bob (after Clean Code & The Clean Coder) will be something like: The Clean Architecture.

Enough said: time to try it in action in your own projects. You won't regret it!