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 when to use microservices architecture


Taking into account the characteristics of an application based on the architecture of microservices, we can establish some criteria of when to use microservices architecture, as shown in the following bullet list:

  • When a system grows in its amount of requirements and functionalities, meaning that it has evolved quickly. In this case, the system begins to mix the responsibilities between its modules.
  • When we need to reuse services.
  • When the centralization of the APIs begins to block the evolution of the system.
  • When there is a need for new features, APIs, libraries, and frameworks, and we do not want to rewrite all of the software for this.

Imagine that we have a sensational and innovative business model, and we must quickly make an application available for customers to enjoy this business. The adoption of a monolithic model, in principle, would make the application develop quickly, with quick tests and deployments as well. At this point, we...