Patterns of Enterprise Application Architecture

I wish I had read all of the negative reviews rather than the review selected at the time as the top-negative review. This book is an exercise in frustration. One would have to see how far one would get before stopping. I made it almost to the end of the third chapter just before the web-presentation chapter. After reading so many disconnected sentences, paragraphs, and topics, I started to wonder what the author was even trying to do or say. Finally, I came to the conclusion that the author was trying to say everything but wound up saying nothing or worst makes contradictory statements but does not state clearly what he is comparing and contrasting. For example, in one section, the author recommends ORM as the must-have (You should seriously consider buying an O/R mapping tool..., page 37) and then bashes a serous shortcoming of ORM without stating that this is a shortcoming of ORM. (It's usually better to use one query that brings back unnecessary rows than to issue 50 individual queries, page 40) Unfortunately, one would have to deduce this connection based on years of experience having focused on the differences between ORM and using database queries to know that one-to-many relationships in ORM has serious shortcomings--each of the many relationships results in a query. While comparing technologies and making sure to consider alternatives is a great goal and many strive to achieve this balance, the author isn't achieving anything and certainly is not presenting best practices. What I finally concluded is that the author is engaging in a stream-of-consciousness presentation where the author's opinions on everything is deeply intertwined within the text, contradictory information is presented without fully explaining a technology, and worst-practices are presented. For those interested, you can read the book to find out for yourself and wonder if the author really is advocating some worst practice.

The patterns in this book are as relevant today as they were when Fowler wrote them out 14 years ago. You'll find these patterns used in most of the popular (regardless of language) web development frameworks use today. I've owned this book for 7 years and I reference it often as I plan and build enterprise architecture. I came here specifically to write a review after pulling the book down to plan out a new application. To use a cliche, it has stood the test of time.

I read in a review that this book is biased toward java: I must disagree--while most of the example are in java (chosen because its a language most developer, at least, know how to read, if not program in), the concepts are universal and can be applied to almost any object oriented language. I've never programmed an enterprise application in Java--yet, it is my go to book when designing architecture for my language of choice.

So if you are thinking are buying this and think it is dated: Its not.
Or think its for java devs: its not.

There's my two cents

This book is required reading for any solution architects or developers working on enterprise software. While there are many new patterns that aren’t covered in the book, the contents of this book should be second nature to anyone aspiring to design enterprise class solutions.

This is a book that has stood the test of time incredibly well. If you want to understand the patterns and architectural principals *behind* the frameworks people use to make complex business or web software, this is fantastic.

There are no pages from 328 to 345.

As a software developer, the problem space for an application is quite different in the Enterprise than it is for a small domain. This being stated (and is in the book), Mr. Fowler quickly points us to effective patterns to be used for developing enterprise applications. Like the Gang of Four book, this book is a catalog and a good description of the patterns to be used in this space. Mr. Fowler has long been a guru in software engineering and this book clearly shows why. The text is very well written, easy to follow, and indicative of someone who knows what they are talking about, not only from a clear thought process, but from experience as well. This should clearly be a book that sits along with the Gang of Four book on your shelf (Design Patterns) for the Enterprise developer or someone interested in enterprise development.

A great book of well written information. Clear and opinionated with great reasoning behind it. It is showing its age whats called a rich client vs a web gui/presentation.

Motivation

I didn't look at this book for a long time simply because of the word "enterprise." I felt the word was too overloaded to be useful. I've heard too many managers, recruiters, and other programmers use this word to mean too many different things. Fowler defines enterprise application as "the display, manipulation, and storage of large amounts of often complex data and the support or automation of business process with that data." By that definition every system I've ever worked on has been an enterprise application.

Cons

A dense, tough read. I almost wish I was at a whiteboard or kept a notepad while reading.

Pros

Fowler gives a fantastic presentation of how to design software using databases, distributed components, etc. This is given through good narratives and anecdotes of Fowler's own experiences, and also through the patterns distilled from these.

The best thing I can say about this book is I would put it fourth in the list of books-I'd-like-anybody-I'm-working-with-to-have-read, right after to Design Patterns, Refactoring, and Extreme Programming Explained.

Summary

As with most patterns books, not everything in here is an amazing revelation, but the common approach, terminology, and ways of categorizing problems and solutions make it very valuable.

Programmers who utilize design patterns and refactoring, and who work on software systems involving distributed components and/or databases should take a look at this book.