Book Image

Java EE 8 Design Patterns and Best Practices

By : Rhuan Rocha, Joao Carlos Purificação
Book Image

Java EE 8 Design Patterns and Best Practices

By: Rhuan Rocha, Joao Carlos Purificação

Overview of this book

Patterns are essential design tools for Java developers. Java EE Design Patterns and Best Practices helps developers attain better code quality and progress to higher levels of architectural creativity by examining the purpose of each available pattern and demonstrating its implementation with various code examples. This book will take you through a number of patterns and their Java EE-specific implementations. In the beginning, you will learn the foundation for, and importance of, design patterns in Java EE, and then will move on to implement various patterns on the presentation tier, business tier, and integration tier. Further, you will explore the patterns involved in Aspect-Oriented Programming (AOP) and take a closer look at reactive patterns. Moving on, you will be introduced to modern architectural patterns involved in composing microservices and cloud-native applications. You will get acquainted with security patterns and operational patterns involved in scaling and monitoring, along with some patterns involved in deployment. By the end of the book, you will be able to efficiently address common problems faced when developing applications and will be comfortable working on scalable and maintainable projects of any size.
Table of Contents (20 chapters)
Title Page
Copyright and Credits
Dedication
Packt Upsell
Contributors
Preface
5
Aspect-Oriented Programming and Design Patterns
Index

Explaining microservices patterns


Many years ago, I had the opportunity to work as a system architect and developer on an administrative–financial system. This involved the use of modules, such as accounts receivable and accounts payable, inventory control, purchasing, payroll, accounting, and so on.

 

 

The whole system was composed of several modules, and the delivery of the system was constructed in a modular way too. At the end of the application development, we had a large, integrated system with many dependencies between the modules. It was obvious that the system should be integrated, and we knew that very well. However, this integration was made with many dependencies and a strong coupling between modules. Sometime later, we also discovered that the dependencies and strong coupling were unnecessary.

We faced a lot of problems in maintaining the application (such as difficulty in implementing new frameworks and excessive bureaucracy), including the fact that whenever there was a need...