Davi Vieira - Designing Hexagonal Architecture with Java: An architects guide to building maintainable and change-tolerant applications with Java and Quarkus

Copyright 2021 Packt Publishing

This is an Early Access product. Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the content and extracts of this book may evolve as it is being developed to ensure it is up-to-date.

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, ortransmitted in any form or by any means, without the prior written permission of the publisher,except in the case of brief quotations embedded in critical articles or reviews.

The information contained in this book is sold without warranty, either express or implied. Neither the author nor Packt Publishing or its dealers and distributors will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Early Access Publication: Designing Hexagonal Architecture with Java and Quarkus

Early Access Production Reference: B17571

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK

ISBN: 978-1-80181-648-9

Welcome to Packt Early Access. Were giving you an exclusive preview of this book before it goes on sale. It can take many months to write a book, but our authors have cutting-edge information to share with you today. Early Access gives you an insight into the latest developments by making chapter drafts available. The chapters may be a little rough around the edges right now, but our authors will update them over time. Youll be notified when a new version is ready.

This title is in development, with more chapters still to be written, which means you have the opportunity to have your say about the content. We want to publish books that provide useful information to you and other customers, so well send questionnaires out to you regularly. All feedback is helpful, so please be open about your thoughts and opinions. Our editors will work their magic on the text of the book, so wed like your input on the technical elements and your experience as a reader. Well also provide frequent updates on how our authors have changed their chapters based on your feedback.

You can dip in and out ofthis bookorfollow alongfrom start to finish; Early Access is designed to be flexible.We hope you enjoy getting to know more about the process of writing a Packt book. Join the exploration of new topics by contributing your ideas and see them come to life in print.

1. Why Hexagonal Architecture?
2. Wrapping Business Rules inside Domain Hexagon
3. Handling Behavior with Ports and Uses Cases
4. Creating Adapters to Interact with the Outside World
5. Exploring the Nature of Driving and Driven Operations
6. Building the Domain Hexagon
7. Building the Application Hexagon
8. Building the Framework Hexagon
9. Applying Dependency Inversion with Java Modules
10. Adding Quarkus to a Modularized Hexagonal Application
11. Leveraging CDI Beans to Manage Ports and Use Cases
12. Using RESTEasy Reactive to Implement Input Adapters
13. Persisting Data with Output Adapters and Hibernate Reactive
14. Setting Up Dockerfile and Kubernetes Objects for Cloud Deployment
15. Good Designing Practices for Your Hexagonal Application

A software that's not well organized and lacks sound software architecture principles may work just fine but develop technical debt over time. As new features are added, the software may become more complex to maintain because there is no common ground to guide code changes. Based on that problem, this chapter explains how the hexagonal architecture helps tackle technical debt by establishing an approach where business logic is decoupled from technology code, allowing the former to evolve without dependency on the latter.

In this chapter, we will cover the following topics:

• Reviewing software architecture
• Understanding Hexagonal architecture

By the end of this chapter, you will learn about the hexagonal architecture main concepts: entities, use cases, ports, and adapters. Also, you'll know the basic techniques to start applying hexagonal principles in your projects.

To compile and run the code examples presented in this chapter, you need the latest Java SE Development Kit and Maven 3.6 installed on your computer. They are all available for Linux, Mac, and Windows operating systems.

You can find the code files for this chapter on GitHub at https://github.com/PacktPublishing/Designing-Hexagonal-Architecture-with-Java-and-Quarkus/tree/main/chapter1.

The word architecture is old. Its origin in history remounts to times when man used to build things with rudimentary tools, often with his own hands. Yet, each generation repeatedly overcame the limitations of its era and constructed magnificent buildings that stood to this day: take a look at the Florence Cathedral and its dome designed by Filippo Brunelleschi, what an excellent architecture example!

Architects are more than just ordinary builders who build things without much thinking. Quite the opposite, they are the ones who care the most about the aesthetics, underlying structures, and design principles. Sometimes they play a fundamental role by pushing the limits to what is possible to do with the resources at hand. The Florence Cathedral, as has already been said, proves that point.

I'll not take this analogy too far because a software is not like a physical building. And, although there should be some similarities between building and software architects the latter differs considerably because of the living and evolving nature of their software craft. But we can agree that both share the same ideal: to build things right.

This ideal helps us understand what software architecture is. If we're aiming to build not just working software, but an easily maintainable and well-structured one, software can even be considered at a certain degree as a piece of art because of the care and attention to details we employed to build it, so then we can take that as a noble definition for software architecture.

It's also important to state that a software architect's role should not only be constrained to decide how things should be made. As in the Florence Cathedral example, where Filippo Brunelleschi himself helped to assent bricks in the building to prove his ideas were sound, a software architect in the same vein should soil his hands to prove his architecture is good.

A software architecture should not be the fruit of one person's mind. Although, there are a few who urge others to purse a path of technical excellence by providing guidance and establishing the foundations, for an architecture to evolve and mature it's necessary to have the collaboration and experience of everyone involved in the effort to improve software quality.

What follows is a discussion around the technical and organizational challenges we may encounter in our journey to create and evolve a software architecture to help us tackle the threat of chaos and indomitable complexity.