Patterns of Enterprise Application Architecture

Rating:
Summary: Application Architecture
Review: An excellent resource to understand the different architecture patterns, kept very simple and precise to the point.
Thanks to the author for coming up with this book.

Rating:
Summary: simply fantastic
Review: anyone out there who is familar with fowler's previous titles, articles, or his site know that he has a knack for insight and clarity. this title continues his tradition of excellence. simply fantastic.

Rating:
Summary: Book Titles That Make a Good Sell
Review: Book Titles That Make a Good Sell

There were times when Enterprise, Architecture
and Patterns titles sold very well, even if the books
themselves did not offer a big deal of information...

If you are looking again for a glossary type of patterns,
plus a ton of source code and UML diagrams, but
neither Architecture nor Enterprise, you may consider
adding this book to your bookshelf. It may sit there for a
while until you find some use for it.

It is a bit difficult for me to identify the book
with Enterprise and Architecture even if its title
suggests so, and it is more difficult for me to understand
how the first 106 pages are affiliated to the rest of the
book, called Part 2, the Patterns.

Here are some points to consider:

1. WEB TECHNOLOGIES? If you are looking for
Enterprise Architecture Patterns, you will be surprised to
find here a strong affiliation between Enterprise and Web
technologies. Coupling Web technologies and Enterprise may

not be reflecting today's real world. Surprisingly, only
about 10%-15% of our Enterprise technologies are Web related,
the rest are still legacy technologies.

2. ARCHITECTURE ENTERPRISE PERSPECTIVE: The author
introduces a collection of patterns, which suggest solutions
to enterprise architecture challenges, but the perspective is
shallow and single dimensional. This is the same as looking
at a problem from a one inch distance rather than seeing the big
picture first. This leads me to believe that the book targets
mostly developers rather than designers and architects.

3. ENTERPRISE ARCHITECTURE AND DATABASE CONCEPTS: The
author dedicated many topics and references to database
issues such as Database Connections, Data Sources, Meta Data,
Optimistic and Pessimistic Locking etc. The book is too heavy
on database solutions, rather than pointing first to the
Problem Domain. It is a kind of a Backwards solution to
enterprise architecture challenges.

4. THE DISTRIBUTED OBJECTS DILEMMA: The suggestion not
to distribute objects on networks is not a careful
proposition in today's technology. The distribution of your
processes, objects, models and subsystems contribute a great
deal to enterprise reusability. If the author bothered to
take a look at today's application server technologies, he would
notices that many vendors already introduced a workable
solution to delinquencies caused by object distribution such
as Replica Aware Stubs or Object Replication techniques.

Michael Bell


Rating:
Summary: Don't be afraid of the word Enterprise in the title
Review: Don't be afraid of the word Enterprise in the title, this book is relevant even if you work only on small/medium size applications. Fowler covers lot of database and data related patterns and quite a good amount of material is related to browser-based client GUIs.

Rating:
Summary: Would have been a great book 2-3 years ago
Review: First, I'd like to say that I think Marin Fowler is awesome. I've been a long time fan of his and I really enjoy his talks and his books. So when you read this review, you can tell that it pains me to write what I have to say. I don't want to rip apart his book so that he potentially sells fewer copies - that's not my intention at all. By writing 3 books myself, I appreciate that authors don't make a lot of money for developing the book itself. Usually people like Martin write books for the experience and to generally help people.

That being said, many developers will unfortunately not find this book very useful. Many of the patterns Martin shows us have a lot of dependency on the platform you are using to implement the application. For instance, if you use Microsoft's .NET platform, you are going to be leaning towards a Table Module instead of a Domain Model. If you do not use a Table Module, you will not be able to take advantage of a considerable amount of functionality that is provided for you within the .NET platform. In Java, the same is true; the Table Module doesn't look as appealing if you are using EJBs, JDO or even Hibernate - you won't ever consider it.

Many of the patterns in the book have this characteristic described above, so architects won't actually learn anything from them. In other words, architects will not be able to take advantage of these alternate design patterns without some initial headaches that are often not worth it because the platform they use restricts and penalizes their usage.

Another complaint about the book is that many of the patterns are already available as frameworks. For instance, many of the presentation patterns are handled by frameworks like Struts or Webwork. In these cases, learning about the patterns that are associated with these frameworks will provide little value. These patterns have already been discussed many times before in other books like "Advanced Java Server Pages" for example.

The same could also be said for persistence frameworks of O/R mapping tools. There is literally over a 100 pages (in a 500 page book) that talk about lazy loads, unit of work, locking strategies, metadata patterns and inheritance mappings. Although sometimes they are useful, in most situations the developers would be abstracted away from all these underlying mechanics using a good persistence framework or O/R mapping tool. I realize not all that the this is true, but implementing Martin's suggestions would take a month or two alone if you didn't buy anything off the shelf - that's too much time to waste. Martin should have talked more about these tools and the patterns they currently implemented instead as this is a more pragmatic approach.

Martin also doesn't talk about the load-on-startup servlet that can be used to store application-scoped values in the ServletContext (for J2EE systems) in his Registry pattern. This was unfortunate because many non-ejb systems use this approach. Considering the book advocates using POJOs, JDO or JDBC instead of EJBs (which is sound advice in practice for most systems), they didn't cover the registry alternates for this approach. Many of us use containers like Resin because they are extremely fast and have no need for EJB development.

Coming from three different environments myself (PHP, .NET and J2EE), I was disappointed that I didn't learn anything from this book. I had, in fact, learned about many of these patterns on my own, but didn't exactly know what they were called. This left me disappointed, but it's not Martin's fault. I don't mean to build me up that I know everything, but I think I've reached a plateau when it comes to designing and architecting systems - I'm good at it. If you happen to be a good designer too and you think you might want to broaden your knowledge, then this book won't help in those areas. If this book doesn't, I don't think you'll find another book that will either. So again, this isn't Martin's fault.

Now before you say something, Martin explicitly states in his book that many experienced designers *will not* learn much. He mentions more than a few times that this book is meant to enhance the communication between architects and designers more than anything and that it is meant to be a documented repository of patterns that we know as an industry and use over and over. I completely agree with these statements. Thus, the book has value in these regards and it will definitely help the industry evolve and mature.

I know I've said some negative things about the book, but let's face it - this is Martin Fowler! The quality and style of the writing is top notch and the organization of the information couldn't have been better. The explanations and examples are very clear and this book is what it claims to be. In this respect, the book should be regarded as the best in its market.

I would advocate purchasing this book in combination with "EJB Design Patterns" and "Expert One-On-One: J2EE Design and Development" for the J2EE developer. As for you .NET folks, I have no idea. From experience, I suspect that .NET developers will have even less use for this book since Microsoft has limited your choices about design in favour of simplifying the platform. That's one of the major differences between J2EE and .NET, and Martin can't control that either.

Overall, this is a good book. I give it only 3 stars, however, because of the initial problems described above.

Rating:
Summary: The right path to creating enterprise applications.
Review: Fowler avoids giving a precise definition of an enterprise application, preferring to list a set of characteristics that most share. In general, they are very large systems, with many user interface screens used to concurrently access and update an enormous amount of data. In nearly all cases, the data must be persistent, in fact it most often is very persistent, meaning that it has to live through iterations of the software, alterations of the operating system, changes in the hardware, and staff and programmer turnover.
Furthermore, enterprise applications usually must communicate with other applications, which are often just as large and complex. Examples include payroll and patient records, credit card processing, insurance claim processing, banking, and foreign exchange trading. In short, most of the programs that run the modern global economy, which are many of the most complex software projects currently in use. Finally, the programs must be constructed so that they can be "easily and quickly" changed by people who did not create them to adapt to conditions that can change very quickly and often without any input from the programmer. With so much at stake, there must be a set of best practices, which is what is captured in this book.
The patterns of software construction explained by Fowler are generally in the small, in the sense that they describe specific operations rather than demonstrate a large architectural form. Each of the specific patterns is presented by first listing a one-sentence description of the purpose of the pattern and a UML diagram illustrating the structure. This is followed by sections describing how the pattern works, when to use it and one or more examples demonstrating specific implementations of the pattern using source code skeletons. Both C# and Java are used in the demonstrations, which does not create an understandability problem. The languages and contexts are so similar that anyone who can understand either one will have no problem reading and understanding the code.
Some examples of the fifty one patterns listed on the inside front cover are:

Lazy load - where an object will load only the data currently needed, but does maintain links to all other data that may be needed.

Front controller - a single handler object that consolidates all requests made for a web site. It can then send requests to the specific objects for services such as security, internationalization issues and specific displays targeted for particular users and locations.

Optimistic offline lock - used to prevent conflicts when concurrent business transactions are executing. The solution is to roll back the transaction when a conflict is detected.

Server session state - keeps the data for the session stored on a server in a serialized form.

While the examples are often of necessity extremely simple, they do illustrate some of the most effective and tested solutions to common software development problems. Therefore, this is a book that no builder of software that can be considered an enterprise application should be without. It is hard to believe that there is an enterprise application being constructed anywhere that does not involve the solving of many of the problems listed in this book.
My only complaint is the occasional bad English that appears. For example, on page 100 there is the phrase, "The only reason I've concentrating on Java . . . " and on page 119 the phrase "One factor that comes into this is comfortable used the development team is . . . " appears. While no book is error free, this type of error is frequent enough to make one wonder about the quality of the final editing.
There is nothing harder than making effective and efficient software that will run the IT equivalent of forever. That is what enterprise applications are supposed to do and if you are one of the minions tasked with doing your part to build one, then put yourself on the right path and read this book. You and everyone else who interacts with the software will be rewarded with a better experience.

Published in the online "Journal of Object Technology", reprinted with permission.

Rating:
Summary: He still writes like a normal person
Review: Fowler is such a standout in the way he writes. As fun as it is for some of the guys to write as if they had to pay a dollar for every word anyone understood, well, it's not fun for us. Instead of Problem Statement, Forces, Strategies, blahblahblah, Fowler just has two main categories:

What It Is
How to Use It

This rocks.

And as another reviewer mentioned, he addresses that huge headache, O-R mapping. This is a very good thing.

Go ahead, get it.

Rating:
Summary: Amazing information, the successor to [Gang of Four]
Review: Got this book last night, and am very impressed. I had read one of Fowlers previous books (Analysis Patterns) and had not been terribly impressed. Do not confuse the two books - they are worlds apart.

The book follows the same format as Design Patterns [Gang of Four], with the addition of a very helpful cheat sheets on the back inside cover. The book gives overviews of maybe 50 (I did not count) patterns commonly found in object-oriented systems.

IMO, the identification of the patterns themseleves is the great achievement of this book. The descriptions are great, with examples in Java and C#. I found the examples hard to read, because the code of a single class is often interspersed with comments, as well as code from other classes. A minor annoyance in the scheme of things.

This is not a book I will ever read from cover to cover - I found myself skipping from chapter to chapter to get brief overviews of what each pattern involved. Sortof a recursive read :)

Overall, for object oriented programmers, I would say "buy the book". I think that it will become a classic, as "Design Patterns" has already. Well worth the (somewhat high) price.

Rating:
Summary: Great book, but nothing particularly new
Review: I agree wholeheartedly with an above post which pointed out that the subject material is mostly known to the average enterprise developer. I am at best an average developer and found I'd already thought of much of this stuff myself.

One thing I would like to add is that this book was still excellent reading and skimming through the patterns sparked my creative energies. I find that when I read through it, even if I 'know' the patterns already, it helps me explore their organization and consequences.

I was disappointed that I wasn't blown away with helpful new concepts, but quite happy with my purchase all the same. Buy this if you want a thorough guide to EAA and maybe some enjoyable afternoon reading.

(The following was added about 2 months after the original review) After owning this book for awhile, I've found it more and more indispensible. My original review, above, mentions that few of the concepts seem new, however, now that I've read it more thoroughly and applied some of the concepts, I don't think that 'mind-blowing originality' is what I should have been looking for.

Fowler's 'Refactoring' is another example of a great book without any stunningly original concepts. Like Refactoring, PEAA can serve as a great guide to page through when you're stuck on a project and need to review your options.

Rating:
Summary: Required reading, but definite J2EE bias
Review: I am a fan of Fowler's and especially his "Refactoring" book, which I also rate as a must read for the serious programmer.
Fowler's new book is an attempt to do for Enterprise Application Architecture what "Design Patterns" (i.e., GOF) did for OOP.
Unfortunately,while it is an excellent book, there are issues...

1)First, Design Patterns is a very dense and scholarly read. It is also, frankly, a difficult read. However, after you have spent a couple of days trying to digest a pattern from Design Patterns, you realize, in many cases, you have had an experience with something profound. Even the GOF authors, in the preface, attempt to console readers by admitting "We didn't understand it all on the first writing!". Fowler's book, by contrast, is not on the same level, and can be understood on a first read. Perhaps this is what other reviewers were sensing when they indicated it was for the novice architect?

2) Fowler does NOT address security. How then,does the word "Enterprise" get the priviledge of adorning the title of his book? Enterprise design should be secure design. But, this will usually require a trade off --- more secure, less performance...or less secure, more scaleable...Fowler does not consider this. Example: A chapter is devoted to the "Table Data GateWay" pattern. The gateway pattern might be OK for J2EE...but it is not the most secure, or the best for performance,in .Net... The problem is it constructs its SQL statements in line, rather than using stored procedures. This allows SQL insertion attacks if your coders are sloppy, and also does not take advantage of the precompiled nature of sprocs.

3)There is a J2EE bias. This probably is a good thing as the J2EE architectures tend to be more mature and contain good ideas...but you should be aware of it if you are a .NET programmer. Not all of the patterns will be immediately useful to .NET, but will require a careful implementation.

4)Fowler passes on some of the tough questions. On page 93, while discussing RPC calls versus XML based messaging, he says "my preference is for a message - based approach that's inherently asynchronous." I agree. (RPC style is not the really suited for async, whereas document style messaging is) He then says it is too large of a topic, so does not cover it. Well, if it is the best way, it needs to be covered in an Enterprise level book, no?

While I may seem to be critical of Fowler's book, I really think it is excellent with fine ideas. But, especially if you are from .Net, implement the patterns with care, and then only you have checked against Microsoft best practices. This is not to say Microsoft is always right, but get the second opinion anyway.