Patterns of Enterprise Application Architecture does exactly what it sets out to do: provide the reader with a catalog of proven enterprise level patterns and the knowledge to use them. Fowler describes an architectural pattern as "...the major components of a system and how they interact" (p. 2) and "...the decisions that developers wish they could get right early on because they're perceived as hard to change" (p. 2).
While most of the patterns in this book are nothing new to experienced developers and architects, they do provide a common vocabulary that can be used to discuss these patterns. For the less experienced software developer, this book is a great opportunity to become familiar with many of the design issues you will come across and patterns that others have successfully used to overcome those issues.
Many times developers will find themselves looking for a better way to implement or improve a certain aspect of their application. The patterns in this book are those that you will find yourself using when you are looking for a way to improve your application. Generally these patterns are discovered through trial and error, however Fowler has conveniently provided us with catalog of the common architectural patterns that he and his team have successfully used.
Patterns of Enterprise Application Architecture is divided into two parts. The first part of the book is a narrative, which gives an overview of the patterns, including the pros and cons of each one. Each chapter is a logical grouping of patterns in domain areas such as Layering, Organizing Domain Logic, Mapping to Relational Databases, Web Presentation, Concurrency, Session State and Distribution Strategies.
The second part of the book is the actual catalog of patterns. Each chapter is again a grouping of similar patterns for quick reference. With each of the patterns comes a description of the pattern, a section on how the pattern works, when to use the pattern, pointers to additional reading, and examples. Most of the examples are written in Java, although the occasional C# example shows up. The examples are simplified for obvious reasons, however they are enough of an example that one can easily understand the pattern and extend and/or modify it as needed.
One pattern I found interesting was a pattern called Lazy Load, in the Object-Relational Behavioral Patterns chapter:
An object that doesn't contain all of the data you need but knows how to get it.
For loading data from a database into memory it's handy to design things so that as you load an object of interest you also load the objects that are related to it. This makes loading easier on the developer using the object, who otherwise has to load all the objects he needs explicitly.
However, if you take this to its logical conclusion, you reach the point where loading one object can have the effect of loading a huge number of related objects--something that hurts performance when only a few of the objects are actually needed.
A Lazy Load interrupts this loading process for the moment, leaving a marker in the object structure so that if the data is needed it can be loaded only when it is used. As many people know, if you're lazy about doing things you'll win when it turns out you don't need to do them at all (p. 200).
Fowler then goes on to describe four different techniques for lazy loading: Lazy Initialization, Virtual Proxy, Value Holder, and Ghost Objects.
Even with this brief description you can immediately see the benefits of using the Lazy Load pattern. Maybe you've used this pattern or something similar in the past or maybe you see a way that this pattern can be a benefit if used in your current project. Either way it's important to carefully weigh the pros and cons when deciding to use a pattern. Architectural decisions are not decisions that can easily be changed once a project is in full swing and reams of code have been written. If an applications design has to be changed or modified midway through a project, serious setbacks will occur as your team struggles to fix the problem and then make up the time that was spent fixing the problem.
Overall, Fowler's narrative and explanation of each of the patterns provides more than enough information for the reader to walk away with a firm understanding of the pattern, when to use it, and when problems can occur with its use.
The best way I found to read this book was to first read a chapter from the discussion section of the book, then familiarize myself with the patterns discussed in that chapter, then go back and reread the discussion chapter if I found I wasn't familiar with one of the patterns. If you are a seasoned developer you can probably skip the discussion section of the book and go right to the catalog of patterns. If you are a new to intermediate level developer, reading the narratives will greatly help your understanding of the patterns.
This book assumes that you are familiar with UML and are familiar enough with Java to understand basic examples. A previous reading of Design Patterns (ISBN: 0201633612) is helpful but not necessary.
I would deem Patterns of Enterprise Application Architecture as a "must read" for anyone who does enterprise level development, whether new to the software field or a seasoned developer.