Modern Java EE Design Patterns book review

3 minute read

My kindle paperwhite says in the beginning of the book that the time to read this book is 2 hours and 55 minutes. Time spent reading was worth it.

About the author

The book that I’m going to make a review is called Modern Java EE Design Patterns writen by Markus Eisele a Java Champion, former Java EE Expert Group member, Java community leader of German DOAG and a very well known figure in the Enterprise Java world.

This book is about …

The book talks about building scalable architecture for sustainable enterprise development. The main emphasis is on understanding Java Enterprise edition (Java EE) design patterns, as well as how to work with new development paradigms, such as microservices, DevOps and cloud based operations. Shows how to migrate existing monoliths into more fine-grained and service oriented systems by respecting the enterprise environment.

Towards a new architecture

In the beginning it talks about the difficulties that have large organizations that need a much higuer level of standarization than startups or small companies and how Java EE has become an standard platform across a great number of enterprises to build complex applications that are stable in the long term.

Says that traditional enterprises have become business-centric and treat IT and operations as cost centers but the good news is that many organizations have started to take notice and are undertaking changes towards easier and more efficient architecture management that scales up.

From monoliths to microservices

Talks about how the typical enterprise Java application has evolved from a monolith to use microservices architecture approach in part because the changes in the software are nowadays more frequent in a world of agile methodlogies that promote iterative and incremental changes, that test hypothesis rather than analysing if something wil be sucessful or not, during long periods of time before trying it.

Today’s most relevant architectures rely on containers to define the software stack to run and provide enough flexibility to projects while maintaining manageability alongside cost-effective operations. Cloud infrastructures help to pay what you use with rapid provisioning.

Microservices are not always the best choice

However, microservices is not always the best approach. It should not be considered unless you have a system that’s too large and complex to be built as a classical monolith. The majority of modern software systems should still be built as a single application that is modular and takes advanage of state-of-the-art software architecture patterns. Martin Fowler explains in this post that in small applications can be counterproductive.

Microservices Best practices

What I found more interesting was the Microservices Best practices section, that those are like microservices commandments that you should follow in this kind of architecture:

  • Design for automation (Continuous delivery (CD))
  • Design for failure (Service load balancing and automatic scaling, Retry on failure, Circuit breaker, Bulkheads, Timeouts)
  • Design for data separation (Separate datastores)
  • Design for integrity (One service related exactly to one transaction, use transactions, separate reads from writes, event-driven design, use transaction IDs)
  • Design for performance (Load test early, load-test often, use the right technology for the job, use API gateways and load balancers, use caches at the right layer)
  • Independently deployable and Fully contained
  • Crosscutting concerns (Aspect oriented programming (AOP), Dependency injection (DI))
  • Security
  • Logging (Kibana, Elasticsearch, Logstash)
  • Health checks
  • Integration testing (Arquilian)

Bonus: A really good article about Microservices by Martin Fowler that can help understand all those principles.


This is a really good book to learn about how new architectures can help deliver software faster and scale in a world of continuous changes that we live in. Those changes are accelerating and we need a new way to evolve those systems that are used for milions of users which need to be available 24 hours per day 7 days a week.

I won't give your address to anyone else, won't send you any spam, and you can unsubscribe at any time.
Disclaimer: Opinions are my own and not the views of my employer