Patterns of Enterprise Application Architecture

This book started after Dave Rice and I gave some talks on J2EE architecture and mulled over how the concepts we had learned in C++, Forte, CORBA, and Smalltalk had been crucial to us developing good designs in Java. With this book I wanted to set many of these patterns down to help developers whatever their platform. These turned out to be very valuable when we started to use .NET in 2002 and Ruby in 2007.

The book is a Duplex Book. The first part is a short (100 page) tutorial on enterprise application architecture. The bulk of the book is the reference to forty or so patterns. All of these patterns are ones that I've seen in the field, usually on many different programming platforms.

Each pattern describes details of how it works and when to use it, together with code examples in Java, C# or both. (I picked these languages because most software developers can read them, not because of any particular coupling or opinions about the language).

The main topic areas are: how to layer an enterprise application, how to organize domain logic, how to tie that logic to a relational database, how to design a web based presentation, some important principles in distributed design, and handling of what we call "offline concurrency" - concurrency that spans transactions.

I've been fortunate enough to have some excellent contributors to this book, most notably Dave Rice - who wrote a good tenth of it. Also joining in are Matt Foemmel, Edward Hieatt, Robert Mee, and Randy Stafford

I wrote this book in the early noughties, but my colleagues and I find the patterns are still relevant today. Our hypothesis then was that the essential problems and solutions in software architecture don't really change that much - that certainly has been true for the last decade.

Another change since I wrote the book is that many patterns are now implemented by common frameworks (particularly with database interaction). This doesn't mean that developers no longer need to understand this material. Frameworks still require you to make decisions about how to use them, and knowing the underlying patterns is essential if you are to make wise choices.