Preface

Since I started to work in software development, I have always felt overwhelmed by the recurring challenge of untangling and learning complex code. For me, part of that complexity derived from tight schedules, speed for speed's sake, feature quantity over code quality, and management pressure to deliver working software no matter the consequences. Under such circumstances, I always find it hard to find enough time for refactoring and other software quality concerns. And I also considered it unfair to blame people who had to write poorly structured code because they had no other choice.

For those interested in economics, there is an axiom that says we're always in a state of scarcity. Nothing is unlimited in this world. Certain people may experience abundance, but the harsh reality is that all resources are scarce: water, food, electricity, money. They all are served in a limited amount. Wise, and very often richer, are those who know how to use their resources intelligently to produce good results. This scarcity condition cascades to all human activities. Software development is one of them.

Every software project is given a limited number of resources to be carried out. We call successful the software project that knows how to use its resources intelligently. Working software is the most important output of a successful project. Unfortunately, this is not the only success criteria. If we deliver working software that is hard to maintain and expect to change that software in the future, then we're not using our resources intelligently. So, in my view, a successful software project delivers working and maintainable software.

But how can we create working and maintainable software with scarce resources? I think this question has existed and has remained partially answered since the first line of code was written. I say partially answered because the circumstances of every software project may be so peculiar that it's hard to find an answer that encompasses all possibilities. Software architecture is one of the efforts to organize ideas supporting the creation of well-structured and maintainable software.

One notable software architecture effort came from a guy called Alistair Cockburn. He was aware that a software system might contain code that exists only to solve business problems. On the other hand, he noted that there is also code that exists only to allow the software system to integrate with external systems and technologies. He then conceived an approach to organize the code and avoid the problems that arise when we mix code that solves business problems with code that integrates technologies. He gave that approach the name hexagonal architecture.

It's the goal of this book to explore and extend hexagonal architecture ideas. More than that, we aim to frame hexagonal architecture in the context of a recent trend in the technology industry: cloud-native development. We live in the cloud era. It's hard to talk about any software development topic and ignore how it relates to the cloud's contemporary software practices. To help us in such an undertaking, we chose Quarkus as the cloud-native framework to guide us in this fascinating cloud-native development world.

You can expect a hybrid approach where theory and practice are blended to improve the learning experience. We'll spend some time discussing concepts, but we'll also have fun by dirtying our hands while putting these concepts into practice.

You may have reached a dead-end in your software project where things are so hard that new features are too complex to add and existent ones are equally difficult to maintain. Maybe you're an enthusiast searching for new ideas to improve your code base. No matter your reasons, I invite you to be my guest on this enlightening learning journey.