You're reading from Designing Hexagonal Architecture with Java An architect's guide to building maintainable and change-tolerant applications with Java and Quarkus

Product type Paperback

Published in Jan 2022

Publisher Packt

ISBN-13 9781801816489

Length 460 pages

Edition 1st Edition

Languages

Java

Tools

Quarkus

Concepts

Software Architecture

Author (1):

Davi Vieira

View More author details

Table of Contents (21) Chapters

Preface

1. Section 1: Architecture Fundamentals

2. Chapter 1: Why Hexagonal Architecture? FREE CHAPTER

3. Chapter 2: Wrapping Business Rules inside Domain Hexagon

4. Chapter 3: Handling Behavior with Ports and Use Cases

5. Chapter 4: Creating Adapters to Interact with the Outside World

6. Chapter 5: Exploring the Nature of Driving and Driven Operations

7. Section 2: Using Hexagons to Create a Solid Foundation

8. Chapter 6: Building the Domain Hexagon

9. Chapter 7: Building the Application Hexagon

10. Chapter 8: Building the Framework Hexagon

11. Chapter 9: Applying Dependency Inversion with Java Modules

12. Section 3: Becoming Cloud-Native

13. Chapter 10: Adding Quarkus to a Modularized Hexagonal Application

14. Chapter 11: Leveraging CDI Beans to Manage Ports and Use Cases

15. Chapter 12: Using RESTEasy Reactive to Implement Input Adapters

16. Chapter 13: Persisting Data with Output Adapters and Hibernate Reactive

17. Chapter 14: Setting Up Dockerfile and Kubernetes Objects for Cloud Deployment

18. Chapter 15: Good Design Practices for Your Hexagonal Application

19. Assessments

20. Other Books You May Enjoy

Enabling reactive behavior on output adapters

One of the most important benefits of using hexagonal architecture is the improved flexibility to change technologies without significant refactoring. The hexagonal system is designed in such a way that its domain logic and business rules are oblivious about the technologies utilized to execute them.

There is no free lunch – when we decide to use the hexagonal architecture, we have to pay the price for the benefits that such architecture can provide. (By price, I mean a considerable increase in the effort and complexity required to structure the system code by following the hexagonal principles.)

If you're concerned about code reuse, you may find some practices awkward to decouple code from specific technologies. For example, consider a scenario where we have a domain entity class and a database entity class. One can argue by saying, why not have just one class that serves both purposes? Well, in the end, it's all...