This is quite an old book now, but glancing around at the current crop of mistakes I see being made it occurs to me that it might be a good time to remind people about patterns. One of the foundations of architecture is reuse and standardization is a means to that end. But where do you get good patterns for something that you’ve never seen before? Well, this book is great start. It opens with what seems a possibly too light introduction to architecture, a problem that it recovers from in stages as it works through what is a pretty good catalog of patterns.
You won’t find all the patterns you need in this book and it clearly states that and it does, not surprisingly, have a bit of a pre SOA feel about it. Which leads to the second observation. That this work is considerably technically deeper than the usual “string em together and stuff on a bus” approach. It contains many UML diagrams and code fragments are scattered throughout the book. The way that these have been arranged in 10 sets of patterns presenting about 50 patterns and supported by three chapters of Narratives (think of these as detail design principles) is what makes this book work.
Inevitably any work as technically detailed as this will be susceptible to obsolesce particularly when you consider the way that the boundaries between application and systems software are being blurred by vendors in pursuit of the next market. But, by and large these patterns stand up well and the fact that you don’t use a pattern doesn’t mean that you can’t learn from it.
Although some time has passed since this book was published its approach, variety and volume 500+ pages mean that there must be something in it for anyone interested in pattern based architecture. You won’t read this book cover to cover, but you should read the narratives once in a while and use part two of the book as a reference.
This really is a book for solution architects and technical leads, enterprise architects and even domain architects probably won’t get that much from it. But should for their own education spend at least a week with it; if for no other reason than improving their risk detection skills.
Fowler, Martin (2003), Patterns of Enterprise Application Architecture, Addison Wesley Signature Series, Addison-Wesely, Parson Education, Boston
ISBN 0-321-12742-0
[...] Patterns of Enterprise Application Architecture | Angry Architect [...]
Well said! I would add that the book’s most helpful part is persistence. Being an architect I have used it as an aid to describing the difference between Domain Model and Transaction Script approaches and arguing that former is more adequate to needs of a project. Also, while most of code samples in “persistence department” are obsolete in the light of modern persistence solutions like JPA (actually, already were obsolete in 2008), the patterns behind them are realy help to explain how things work in such frameworks.
Igor,
Perhaps you could gives us your thoughts on the DM and TS approaches in more detail? It’s obviously a space in which you’ve accumulated some knowledge.