Patterns of Enterprise Application Architecture by Martin Fowler

Patterns of Enterprise Application Architecture Reviews

• 
  Matt

  In comparison to other patterns books that I have read, Patterns of Enterprise Application Architecture is one of the weaker ones. I'm afraid that many of the patterns described are now out of date or anti-patterns. The book is now 12 years old and the technology field is a different place.
  
  Many of the patterns in the book focus on dealing with relational databases or non-distributed systems. Relational databases still play a large role in many enterprise applications, but this material either predates or ignores other types of storage like distributed file systems (e.g., HDFS) and key-value storage (e.g., Redis). And with so many web applications using cloud services, horizontal scaling is practically a must for anything serious.
  
  For the record, there are some really good patterns in here like Active Record and Unit of Work. Also, many of the patterns in the general section at the end of the book are quite good. I'm not sure why Fowler did not lead with that material (why describe some complex patterns if you haven't explained a Plugin yet?).
  
  Finally, I did not get much out of the example code. Some of it was bad formatting from my O'Reilly e-book (non-monospaced fonts? really?). But, mostly, the code did not illustrate much to me.
  
  This is a book you might want on your shelf because people may occasionally mention some of the patterns it describes, but don't bother reading it cover to cover like I did.
• 
  Nguyen Huu Anh Vu

  As with other books by Martin Fowler, the writing style is unstable. Some idea are well-explained, some are in dire need for more explanation.
  Even though some examples are out-dated (we now use JSON over XML), the patterns presented in this book can still be useful in modern project.
  Must read for those who want to design architecture
• 
  Daniel

  I re-read this because back then, I only skimmed it, and I thought some of the content might still be relevant today. Unfortunately, this book has not aged very well. Most of the patterns are hardly useful at all in 2014, or even anti-patterns by now.
• 
  Brian

  Another one for us techies...
  
  First off, I don't think you can go wrong with Fowler. I know that many will argue with me on that statement, but at least he gets you thinking and defending the points on which you disagree.
  
  This patterns book is a must have on your shelf as well. Great thing this hard back has a built in bookmark because it is heavily used. This isn't a great read from cover to cover, but it is a wonderful reference book. Anytime that I try to design a new architecture, this book comes in handy to make sure that I am not reinventing the wheel.
• 
  Matt

  I think this is a great book. Most developers should have it on hand as a reference. I say that in spite of the fact that I'm seriously annoyed by patterns fashionistas and Fowler fanatics.
  
  This is not a collection of esoteric design patterns or capital-A architectures. This is a collection of tricks, schticks, and small-A architectures that just tend to show up repeatedly in the wild. Martin Fowler, with his perspective as an idea man and his position as a consultant and thought leader, has observed these and collected them together in a catalog along with some weighty analysis.
  
  An initial read-through is probably a good idea, at least enough to assimilate the introduction and be familiar with the existence of most of the patterns. Out of real-world context, the material feels to me to be very academic and not very practical.
  
  Where it comes together is when I can use the book like a bird guide whilst bird watching: Digging through some code or design docs and stumbling on a mechanism, conceived and implemented by an author who may not have ever heard of PoEAA, and having some recognition like "Hey, this is very similar to a Query Object pattern." Then I can go look it up. Sometimes it helps the task at hand by filling in as the missing documentation; other times it's merely "fun facts".
  
  I've also used this book when putting together my own designs. It can provide useful guidance ("What's an alternative if I don't like our offline locking"). It can serve as a named reference ("By 'Value Object', we mean Fowler's rather than Sun's or Evans's").
  
  In both of the above uses, the book shines when I have a pattern already in front of me and I want to know more. Probably as I get more practice out of putting context into Fowler's analysis, I'll be able to get direct practical value (rather than food-for-thought) out of working it the other way - starting with the academic discussion and being able to visualize real-world tailored specifics rather than idealized implementations.
• 
  Leo Maslovs

  It's one of the best sw engineering books I've read recently.
  
  What I liked the best? The ELI5 (explain like I'm 5) stuff. Yes, it's all known and battle-tested truths out there, most of it found (to my shame) independently, and oh boy, how much time & effort has burn out and flew into the pipe doing so. Still it's so refreshing to get some good and clear read on this ELI5 style; I feel like I'm finally up to the point to be able to explain database isolation levels to 7th grade student myself. I think it's something you come to especially appreciate after your own miserable attempts and failures in the field (read experience).
  
  Yes, book is from 2002. And yes, it didn't age so well. Still it's a very useful combo of ELI5 architecture approaches and good old common ground tricks tricks and patterns. Most of the stuff is still adequate in 2016 as in the 1990, but some of the statements and recommendations have to be taken with a grain of salt (which a good advice regardless which architecture book you are reading).
  
  Having said that, I don't think the book will be easy read to industry new-comers (it doesn't introduce some basics, instead it relies on some common ground knowledge: e.g. B2C applications, mapping tools et cetera..)
• 
  Katrina Theodosopoulos

  I had a hard time understanding the examples because I don't know C# or Java.
  
  However, that's probably the only downfall I found to this book. Still being youngin' in the programming sphere, this book explained many concepts that you won't see explained in other places, and if they are, not nearly as well. I like how the book organizes the patterns, it makes them easier to find. The best way I found to read the book was looking up certain patterns I already knew or heard of, but wanted to learn more. Once you get all those down, go to the other ones you haven't read yet. This book is very dense, and you'll probably have to read it a few times, unless you're a senior developer, then you might run through this book.
  
  I think this book is a must-have for new (or aged) developers. It makes for a great reference. Even if you don't understand what you're reading the first time around, things will eventually start to click. This book helped me encompass a bigger picture of ORMs amongst other things used today.
  
  Would highly recommend, especially if you know Java or C#.
• 
  Bragadeesh

  This book will be more relevant for that ambitious architect who is willing to dedicate a lot of time to comprehensively brush through the basics of basic web design pattern. Since this book was written 15 years before and given that the information technology field is a rapidly changing one, the relevancy and newness is lost. However, I would still recommend it for those who want find the roots and sources of the existing design patterns especially those deal with the enterprises.
  
  One more thing - if you are a seasoned Rails developer, you may and should skip reading this unless you may want to know why and how Rails is successful.
• 
  Paolo Bizzarri

  Still relevant to read
• 
  Matteo Tomasulo

  This book shows its time by now. A lot of this patterns are well implemented inside the most common frameworks or even provided as core language feature which allow you to solve that problem in clearer way.
  
  But the main advantage of the PEAA I think is: terminology. Give the right name to the right things is one of the most common problem in software design specially in new formed teams without great experience.
  And this book, even though its age, still helps in this.
  
  edit:
  After some time I noticed that this book actually gives more advantages than expected, so I raised a star
• 
  Alejandro

  A bit dated, but still a very good read.
  Although most modern frameworks already adopt most of these patterns, it's useful to internalize the motivations as well as the inner workings of each.
  Also, as with any patterns book, it establishes a language that makes discussing architecture with peers easier; and it's pretty clear that the naming put forth here transcended.
  
  Looking forward to reading Integration Patterns.
• 
  Denis Nuțiu

  Very good book, it provides a lot of patterns and knowledge about some techniques that you may never implement by yourself, nonetheless this is helpful when using libraries.
  
• 
  Andrew Dalgleish

  As programming books go, this one is overly boring, and is really meant as a reference. The patterns are important however, and many systems have been implemented with them in mind. The author is very big into Java and Enterprise Architecture and you'll be a bit lost if you're not in those spheres of thinking.
  You pick it up when you have to implement something or understand a system that follows the patterns contained within. Each pattern is annotated with references to other patterns so its easy to see how they all link together.
• 
  Miloš

  Although many of the described patterns are either deprecated or already implemented in most popular enterprise frameworks, it was still very thought-provoking and educational to read about the motivations for their use and ways to implement them - after all, every worthwhile computer science curriculum teaches us how to implement linked lists and a whole other range of data structures that already come out of the box with most languages. Similarly, after reading it cover to cover I tend to consider this book Enterprise Programming 101 :)
• 
  Trevor Price

  This book certainly shows its age. Some patterns remain quite relevant, but in the year since this was published, IDEs and databases have improved dramatically, which renders some patterns totally useless.
  
  And even if this were a more recent book, the format just doesn't lend itself to easy digestion. In fairness to this book, I can't think of a better way to present the material. But there just has to be a better way. Part of the problem is that the examples are based on 14-year-old tech at this point, so many are cluttered up with CRUD boilerplate.
• 
  Joe

  This is the definitive reference on patterns in application development. The Gang of Four book is a classic reference on patterns, but the patterns there are lower level. And they are useful, but never had as much of an impact as this book. When reading this book, I immediately recognized many of the patterns and really value having a vocabulary to talk about application design decisions. This is a must read book for advanced application developers and architects.
• 
  Sumant

  I tried reading this book, but should have read previous reviews before starting this book. The book is clearly outdated in terms of lots of concepts and patterns in it. Also the language is not fluid, and I really got bored reading the few pages I read from this book.
  
  Stopped reading the book, as I did not want to spend my time learning and understanding something in a harder way.
• 
  Josh Readmore

  An extremely influential book - unfortunately, going Domain Model for all data access has turned out to be a monumental failure. But it was a good try - and all of the patterns in this book are common and legit.
• 
  Reggie

  This is a solid book. It wasn't as useful to me as I had hoped, but I'd still recommend it as a good resource.
• 
  André Gomes

  
  
  A must read for software folks.
• 
  Avraam Mavridis

  Definitely a great book but on some parts it is clear that it is a bit "too old". The book is almost 20 years old, so it is not a surprise that some of the patterns Martin describes there are not so "real" nowdays, for example I cant imagine any service that is written the last 6-7years to make use of the Remote Facade pattern. Another thing that shows the age of the book is the use of XML as the main way of transporting data, again, I think JSON (and Protobuffers) have won this battle. Patterns like Data Transfer Object nowdays that GraphQL becomes more and more popular seem like a joke.
  
  If you take into consideration that is a 20 years old book, its a great one, but probably is time for Martin to revisit and release a new edition.
• 
  Piotr

  Disappointing. The book was written in times when SQL databases were an exciting innovation starting to dominate the market. As result many problems described are no longer faced by the majority of programmers, for many we know better solutions than those suggested. This makes the signal to noise ratio rather low. Some patters no longer need to be implemented, as they have become a basic functionality of popular frameworks - all you get is that you understand better why frameworks do some things and which implementation they may choose. I prefer to learn how to solve my problems rather than learn about history of advances in computer science, so I was bored most of the time.
• 
  Lassi Autio

  Book has a good catalog of various patterns. Most of the patterns are explained even too deeply to read when reading the whole book. My recommendation is to read beginnings of each pattern. And if you someday need that pattern then you can read the whole chapter about that pattern.
  From some parts, book is maybe little outdated. For example, web presentation patterns have changed a lot since 2003.
  The book contained some patterns that I was already familiar with but I just hadn't recognized them as patterns.