Book Image

Designing Hexagonal Architecture with Java - Second Edition

By : Davi Vieira
Book Image

Designing Hexagonal Architecture with Java - Second Edition

By: Davi Vieira

Overview of this book

We live in a fast-evolving world with new technologies emerging every day, where enterprises are constantly changing in an unending quest to be more profitable. So, the question arises — how to develop software capable of handling a high level of unpredictability. With this question in mind, this book explores how the hexagonal architecture can help build robust, change-tolerable, maintainable, and cloud-native applications that can meet the needs of enterprises seeking to increase their profits while dealing with uncertainties. This book starts by uncovering the secrets of the hexagonal architecture’s building blocks, such as entities, use cases, ports, and adapters. You’ll learn how to assemble business code in the domain hexagon, create features with ports and use cases in the application hexagon, and make your software compatible with different technologies by employing adapters in the framework hexagon. In this new edition, you’ll learn about the differences between a hexagonal and layered architecture and how to apply SOLID principles while developing a hexagonal system based on a real-world scenario. Finally, you’ll get to grips with using Quarkus to turn your hexagonal application into a cloud-native system. By the end of this book, you’ll be able to develop robust, flexible, and maintainable systems that will stand the test of time.
Table of Contents (24 chapters)
1
Part 1: Architecture Fundamentals
7
Part 2: Using Hexagons to Create a Solid Foundation
12
Part 3: Becoming Cloud-Native
18
Part 4: Hexagonal Architecture and Beyond

Reviewing the layered architecture

Layered architecture, in my view, may emerge when a group of developers in charge of a project do not stop to think about which kind of architecture is more suitable for the software they want to develop. I have observed this scenario in projects where without conscious team planning, the code structure would evolve to some level of separation of concerns where the presentation/API code would be somewhat isolated from the business and infrastructure code. You would not see core business logic in the classes responsible for providing a REST endpoint, for example. You may notice, in such projects, packages named model, repository, service, and controller as hints to a system based on the layered architecture ideas. They are hints because each of those packages usually represents an intent to allocate a specific software responsibility. The code present in the model package is used to represent database entities. The repository package contains classes...