Like many many other things, a hexagonal architecture, is something very complicated and fascinating until you start doing it and then it becomes easy and well understood. This little text is a report about how a group of developers learned about hexagons (or Ports & Adapters if you fancy the longer name).

Just a prior warning: This text is not about hexagonal architecture, but about how to create a very effective learning experience. I will write about hexagons on another occasion.

I work at a company that has many awesome developers and gives us developers slack days on a regular basis to do things like experiments, learn, share, socialize and grow. So with some knowledge and hearsay about hexagons, a group of five developers from different teams and various backgrounds came together for one day and to build a hexagon, just to have done it and learn from this experience. Actually i initiated it, because i had read a lot about different architecture patterns and am eager to try them. Also i had some prior experience with an architecture similar to a hexagon, but i realized that i lacked some deeper understanding. The motivation of my colleagues were similar, with more or less prior experience and book knowledge.

How did we do it?

To get the whole thing started and get everybody on the same page, i gave an impromptu lecture on architectural patterns and the origin of the hexagon - which originated as a communicative tool to model software from Alistair Cockburn (great guy, by the way). I was giving this lecture spontaneous based on my book knowledge (Implementing Domain Driven Design has a very nice chapter about the evolution of architectures) and my prior experiences. And what really got this thing going was the obvious fact that i clearly did not knew everything, which led to all of us engaging in challenging and rewarding discussions. After this discussions everybody was on a comparable level of knowledge.

After the initial lecture and discussions i introduced an incredible simple software project (which we then simplified even further) that we had to build: A software that receives user ratings, stores them and informs a content owner via mail about new ratings.

And then we started Mob-Programming for the next few hours. I started by modelling the first port and then we just blazed through with regular switches, domain logic written with TDD and everybody chiming in with ideas and questions. This was really very productive and we were able to explore many aspects of hexagons - we argued about various mapping approaches for data objects that are passed across the architectural boundaries, about differences between driver adapters and driven adapters, how to differentiate domain logic and adapter logic and possible interactions between bounded contexts. In the end, after just a few hours intercepted by only one break, we had a minimal working hexagon (it could be called a walking skeleton) with one driver and two driven ports and adapters and matching test implementations.

Conclusion

First of all, my personal goal of understanding a hexagonal better, was achieved. Experiencing this code grow and arguing with other well minded developers about it was really something very productive. And i guess my colleagues share this assessment.

What i also find important is, that i was and still am eager to apply the hexagon to a project i am currently working on. But after this experience i am a bit more experienced and would apply this slightly differently. And this slight difference is already very valuable, because it minimizes the risk of the need to redesign afterwards. So this a strong argument for slack days or similar opportunities to learn.

I think my impromptu lecture and the task i prepared (my total preparation time for the whole day was around thirty minutes) really helped getting this experience started and give it a goal and a structure to follow. However i consider these tools useful but not necessary for the learning, because highly motivated developers tend to organize themselves to achieve reachable goals. The interaction was also supported by me not being a trainer, but being a learner as well. But most importantly we had time we needed to finish the exercise - no external meetings or pressure to finish early.

To generalize: If you want to learn something fast and with fun, invite some friendly people who want to learn as well and take the time you need - don't compromise on these. Most other parts fall in place, but can be supported by having a agenda, lecture material and tasks.