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

Defining business rules as POJOs

Back in the day, when enterprise development was strongly influenced by Java 2 Platform, Enterprise Edition (J2EE) (known today as Jakarta EE), there was a technology called Enterprise JavaBeans (EJB) responsible for lifting from developers all the heavy weight required to manage software development plumbing activities related to transaction management, security, and object life cycles. The EJB promise was that developers could focus their energy on developing business features, while the J2EE container would take care of all the infrastructure details. EJB fulfilled this promise, but not without a price. It was time-consuming and boring to create and maintain EJBs in their first versions. There were lots of things to do involving various Extensible Markup Language (XML) configurations and deployment descriptors, and, to make things worse, there was little space to reuse these EJB objects because they had so much boilerplate. They weren't like...