Java Reference
In-Depth Information
The inherent unreliability and complexity of distributed systems are duplicated in a microservice
environment. Every service may be hosted in a distributed way, communicating via networks that
suffer from latency issues, incompatible versions, unreliable providers, hardware problems, and
more. Constant monitoring of network performance is vital.
Conclusions
The monolithic architecture has been used for many years to develop applications and serves small
applications and development teams well. It's easy to develop and test because IDEs are designed to
manage these types of application structures. But as you have seen, it does not scale well and hinders
development. It is difi cult to introduce new technology, and refactoring is expensive.
Microservices decompose into logical services of related functionality. Their small size makes them
easy for developers to understand. Development and deployment are continuous. Scalability is built
into the architecture, and you are not stuck with initial technology decisions.
FINALLY, SOME ANTI‐PATTERNS
The purpose of this topic is to i ll the gap between “classical” patterns and Java EE. You will i nd
many topics discussing anti‐patterns, but there is no harm in discussing a few here.
Anti‐patterns usually occur because of misuse of one or several patterns. A Java EE developer who
has enough experience can easily list more anti‐patterns than patterns. Here are a few that are com-
mon or that you may already have come across.
Uber Class
There is probably no single project without a huge class that serves many purposes and responsibili-
ties. Not only does this violate Java EE principles, but such classes override basic object‐oriented
programming (OOP) principles and must be avoided.
Services that are overloaded with many responsibilities fall into the same category. If you are not a
big fan of OOP, that's i ne, but if you do want to continue to write code in an OOP language, it is
best to keep your classes small and highly cohesive.
Although many others had expressed this anti‐pattern, Reza Rahman may have i rst introduced the
name.
Lasagna Architecture
Java EE promoted layers starting from the early days, which may have resulted in many unnecessary
interfaces and packages. Although this pattern may look like an answer to uber class and monolithic
applications, usually it complicates things unnecessarily.
Lasagna architecture in the OOP world is not much different from spaghetti programming in
structural programming. Too much abstraction is unnecessary and provides no help. Interfaces and
loose coupling are great tools only when you use them in the right amount, in the right context, and
only when they are needed.
