Chapter 12 – Get Your Hands Dirty on Clean Architecture

Chapter 12

Deciding on an Architecture Style

So far, this book has presented an opinionated approach to building a web application in a hexagonal architecture style. From organizing code to taking shortcuts, we have answered many questions that this architecture style confronts us with.

Some of the answers in this book can be applied to the conventional layered architecture style. Some answers can only be implemented in a domain-centric approach such as the one proposed in this book. And some answers you might not even agree with, because they don't work in your experience.

The final questions we want answers for, however, are these: when should we actually use the hexagonal architecture style? And when should we instead stick with the conventional layered style (or any other style, for that matter)?

The Domain is King

It should have become obvious in the previous chapters that the main feature of a hexagonal architecture style is that we can develop the domain code free from diversions such as persistence concerns and dependencies upon external systems.

Evolving domain code free from external influence is the single most important argument for the hexagonal architecture style.

This is why this architecture style is such a good match for Domain-Driven Design (DDD) practices. To state the obvious, in DDD the domain drives the development. And we can best reason about the domain if we don't have to think about persistence concerns and other technical aspects at the same time.

I would even go so far as to say that domain-centric architecture styles such as the hexagonal style are enablers of DDD. Without an architecture that puts the domain into the center of things, without inverting the dependencies toward the domain code, we have no chance of really doing DDD; the design will always be driven by other factors.

So, as a first indicator of whether to use the architecture style presented in this book or not, if the domain code is not the most important thing in your application, you probably don't need this architecture style.

Experience is Queen

We are creatures of habit. Habits automate decisions for us so we don't have to spend time on them. If there's a lion running toward us, we run. If we build a new web application, we use the layered architecture style. We have done it so often in the past that it has become a habit.

I'm not saying that this is necessarily a bad decision. Habits are just as good at helping us to make the right decision as they are at making a bad one. I'm saying that we are doing what we are experienced in. We are comfortable with what we have done in the past, so why should we change anything?

So, the only way to make an educated decision about an architecture style is by having experience in different architecture styles. If you are unsure about the hexagonal architecture style, try it out on a small module of the application that you are currently building. Get used to the concepts and get comfortable. Apply the ideas in this book, modify them, and add your own ideas to develop a style you are comfortable with.

This experience can then guide your next architecture decision.

It Depends

I would love to provide a list of multiple-choice questions to decide on an architecture style just like all those "Which Personality Type Are You?" and "What Kind of Dog Are You?" tests that regularly swirl around social media. I'm the "Defender" personality type and if I were a dog, I would apparently be a Pit bull.

But it isn't as easy as that. My answer to the question of which architecture style to choose remains the professional consultant's "It depends...". It depends on the type of software to be built. It depends on the role of the domain code. It depends on the experience of the team. And finally, it depends on being comfortable with a decision.

I hope, however, that this book has provided some sparks to help with the architecture question. If you have a story to tell about architecture decisions, with or without hexagonal architecture, I'd love to hear about it.

You can drop me an email at tom@reflectoring.io.