A practical guide for software architects and Java developers to build cloud-native hexagonal applications using Java and Quarkus to create systems that are easier to refactor, scale, and maintain Hexagonal architecture enhances developers' productivity by decoupling business code from technology code, making the software more change-tolerant, and allowing it to evolve and incorporate new technologies without the need for significant refactoring. By adhering to hexagonal principles, you can structure your software in a way that reduces the effort required to understand and maintain the code. This book starts with an in-depth analysis of 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 by using ports and use cases in the Application hexagon, and make your software compatible with different technologies by employing adapters in the Framework hexagon. Moving on, you'll get your hands dirty developing a system based on a real-world scenario applying all the hexagonal architecture's building blocks. By creating a hexagonal system, you'll also understand how you can use Java modules to reinforce dependency inversion and ensure the isolation of each hexagon in the architecture. Finally, you'll get to grips with using Quarkus to turn your hexagonal application into a cloud-native system. By the end of this hexagonal architecture book, you'll be able to bring order and sanity to the development of complex and long-lasting applications. This book is for software architects and Java developers who want to improve code maintainability and enhance productivity with an architecture that allows changes in technology without compromising business logic, which is precisely what hexagonal architecture does. Intermediate knowledge of the Java programming language and familiarity with Jakarta EE will help you to get the most out of this book.
Unfortunately there are lots of problems with this book. The domain chosen for the application (managing routers) is one that few readers will be familiar with. The "technical" nature of that domain can be confusing when discussing the important difference between the domain (the "inside") and the outside world and infrastructure, since we often see routers, etc., in that "outside" location. In addition, there is very little "behavior" in the core domain, which means it's not very compelling from a domain-driven design view.
The overuse of patterns, such as Specification and Policy, obscures the architecture. And the inclusion of "Kubernetes" is appealing only as a buzzword and does not add much to the architectural discussion.
The terminology of calling "domain", "application", and "framework" as separate "Hexagons" goes against how most other authors use the term and will be confusing for those reading other materials on the topic. The use of "framework" as the outmost layer is an unnecessary addition; simply calling them Adapters is enough.
I won't get into the misuses of terms like "tech debt" and "POJO" as that's a problem elsewhere, too.
There's an overemphasis on Cucumber tests, which are certainly valuable, but most tests should be unit tests. The lack of a focus on testability is unfortunate, as that is one of the primary strengths of this architecture.
Overall, there's a sense that the author, and others involved, have not read much of the writings out there on the topic, or chose to deviate from terminology used elsewhere without a good explanation of why.
The book does a good job of explaining how to implement a layered architecture. The approach is extremely hands-on, with lots of code.
I was already familiar with hexagonal architecture, having used it before in Domain-Driven Design projects. I started reading this book as a refresher, but I still picked up quite a few new things.
For example, I found that the term "Infrastructure" (as in, Domain, Application, Infrastructure) was always too ambiguous. Instead of "Infrastructure", the author calls this the "Framework" layer, which is much clearer! Now the term "Infrastructure" can be used for actual infrastructure, such as databases, message queues, etc.
The emphasis on Input and Output Ports and their corresponding adapters is also something I haven't seen in other literature.
The last section of the book is a good introduction to Quarkus and Kubernetes. Nothing in-depth, but enough to get started.
The example domain (networks, routers) is indeed too technical, but this is clearly not a book on Domain-Driven Design.
O livro faz uma boa explanação da Arquitetura Hexagonal, especialmente nos capítulos iniciais. A divisão dos capítulos ficou boa e fluida, ajudando na compreensão e fixação dos conteúdos. Minha crítica é relação a quantidade de código que é colocada no livro, acho que isso tomou muito espaço e agregou pouco, já que muito código era parecido, mudando apenas o domínio que ele tratava. Faz uma boa introdução do Quarkus e de tecnologias mais recentes como reactive programming, docker e kubernetes.
Eu vi muita crítica em relação ao domínio escolhido, Gerenciamento de Inventário de Equipamentos de uma Rede..rs, embora não seja algo muito comum, não creio que seja um problema pro entendimento dos conteúdos. Enfim, gostei da leitura e recomendo praqueles que desejam aprender mais sobre Arquitetura Hexagonal na prática.
This is a weird book. It's written in non-idiomatic and often outright weird English. The code examples are great, but the author does not do a good job explaining the DDD concepts behind the code. Make sure to read "Domain-Driven Design: Tackling Complexity in the Heart of Software" and brush up on Jakarta EE patterns before taking on this book.
Better yet, skip this book and read "Get Your Hands Dirty on Clean Architecture: A hands-on guide to creating clean web applications with code examples in Java"
This book is an interesting journey and includes many steps from the initial design to a final product - tested and deployed on kubernetes. It covers a broad range of technology and methodology and is from my perspective a great roadmap.
Due to the roadmap fact it is difficult to name a matching audience, beginners might be overwhelmed, although they might get the best profit from it.
There is lots of repetition, but most of it is due to the before and after view to solutions.