Patterns of Enterprise Application Architecture
The practice of enterprise application development has benefited from the emergence of many new enabling technologies. Multi-tiered object-oriented platforms, such as Java and .NET, have become commonplace. These new tools and technologies are capable of building powerful applications, but they are not easily implemented. Common failures in enterprise applications often...more
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 ...more
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
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 ...more
One more ...more
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 ...more
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
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.
After some time I noticed ...more
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 ...more
Stopped reading the book, as I did not want to spend my time learning and understanding something in a harder way.
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.
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 ...more
Worth reading, even being "old"
(Not so) Long Version
It covers some things in an "outdated" way like:
- Several patterns on the relational/OO mismatch are covered nowadays by JPA, ActiveRecord and friends, so we don't necessarily need to study them in depth;
- The patterns on Web Presentations which were mostly superseded by frontend frameworks;
However, most patterns are still valid, since the challenges of large enterprise systems (even with newer tech stacks / architectures) still have a lot ...more
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 ...more
Generally, classic books talk about fundamentals and abstract contents, it's not a cup of coffee for everyone, because they can fast become boring. It also hard to relate sometimes. Using some of the contents directly without prior research and enhancing the idea is absolutely not brings you much benefit IMO. That's why if a ...more
I did not thoroughly read all the patterns, they ...more
It's important when to use them, but the second part should be used as a reference whenever we feel some of them should be applied.
It's worth noting that most of the modern frameworks make use of some of the patterns described by the book (e.g., Symfony/Doctrine: Unit of Work, Domain Models with Data Mapper, Query Object, Front ...more
At times, it's humorous reading Fowlers assumptions about system design and message passing, but one must put it in context of 2001.
I would recommend this book to any ...more
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 ...more
There's probably other technical books I'd read before this (Clean Code, Working Effectively with Legacy Code, Effective 'Insert lanuage here' etc) but for moving more into the architecture side of things this is a good one.
Goodreads is hiring!
Learn more »