Customer Reviews

Patterns of Enterprise Application Architecture

5 star:		(45)
4 star:		(14)
3 star:		(11)
2 star:		(2)
1 star:		(1)

 

 

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.

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.

This is the best book I've found on J2EE and .Net patterns. I think it's destined to become a classic. I found the discussions on when to distrbute ('sell your favorite grandmother first'), Unit Of Work, Domain Model and Data Mapper patterns extremely useful. It has changed the way I think about enterprise applications.

I think it fits somewhere between the original 'Design Patterns' book, by Gamma, et al, and a book like 'J2EE Patterns' in terms of its scope. 'Design Patterns' describes existing patterns that are applicable to any kind of application. 'J2EE Patterns' describes patterns in terms of one platform (although many of them apply to other platforms as well.) Fowler's book describes a set of patterns that work with a certain kind of application, business apps, but that are applicable to more than one platform.

It's better than the 'J2EE Patterns' book, which doesn't do a good job explaining which parts of J2EE to avoid, and which 'patterns' are in fact workarounds for problems in the platform itself. (For example, the 'Composite Entity' pattern.)

I have to strongly disagree with the first reviewer. Fowler does explain which patterns work best on which platform. The first section of the book gives a good road map for deciding which set of patterns to use for your app. He mentions explicitly that .Net pulls you in the direction of Table Module, but that with J2EE you would be less likely to use that pattern.

As far as the patterns being available in frameworks, I still find it useful to know about the patterns the framework implements. That way you know which framework to select. We recently went through an O/R mapping tool selection process. Reading the Unit Of Work, Data Mapper, Repository, Lazy Load and Identity Map chapters helped *immensely* in that process. Likewise reading the Front Controller pattern gave me some new ideas on how best to utilize the Struts framework. I totally disagree with the notion that "learning about the patterns that are associated with these frameworks will provide little value". Ignorance is definitely not bliss here.

Finally, the idea that because the book 'just' collects and names patterns that already exist somehow decreases its value is hogwash. These are tried and true patterns that many developers have found useful. Naming and clearly describing common patterns is very helpful. This is exactly what the original 'Design Patterns' book did. By this logic, I guess the original reviewer would have given 'Design Patterns' only 3 stars.

It's a great book.

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.

This book has been getting a lot of hype -the followup to Fowler's seminal Refactoring, enterprise edition of the GoF, etc etc.

It's a dense and informative read. If you didnt know anything about cricket, you will by the end, as all its examples are basd on the game. I, sadly, find cricket deadly dull as a consequence of having it force fed at me in the UK educational system. This may bias me against the examples somewhat.

As to the content, well, it is a set of patterns focused on 'enterprise' applications. In this context, enterprise means server-side code connected to a database, usually with a Web Front end. Martin goes into superb depth on how to map from databases to java and .net objects, making you think about whether or not the stuff that your framework of choice gives you is the right tool for the job. Sadly, all that does is make you more aware of the failings of EJB, JDBC, whatever .NET has. Because, unless you are going to roll your own database bridge by hand, you are going to have to run with what they give you -whether it [stinks] or not.

I dont do much O/R mapping. I hand it off to tools like Castor and worry about my real problems: shipping web services to implausible deadlines to be managed by an operations team that phone me whenever something goes wrong. So my problems are web service related 'good API design', and 'executional patterns': how to design code that is easily tested, what is a good strategy for implementing configuration information, what is a good XML format for future flexibility. I also have to worry about the client side: how to architect a client that works well over long haul and intermittent links, and how to present this to the user.

Martin's book doesnt cover these kind of problems. I do like his critique of Entity EJBs (as opposed to session beans), where he observes that because EJBs are all distributable, people tend to do just that, leading to performance problems that are very profitable to him as a consultant.

The implicit message is that these days, he is spending his time tuning object to DB linkages, and not worrying about all the other aspects of the problem. Another reviewer mentioned security, but my concern is about designing for high availablity, a series of practises that focus on redundancy, caching, and interdependencies and self-diagnosis of faults, rather than caring about minutae of O/R binding.

So I'm giving the book 3-stars, as it doesn't suit my problems. Maybe it suits other people better.

-steve

This is by far the best description of enterprise patterns I have read to date.

Fowler points out that none of these patterns are new (and many have been around for a long while), but never have I seen such a vast array of useful enterprise patterns so well documented.

I had heard and/or seen a lot of these patterns already, but the way he describes the patterns and the trade offs involved in choosing the patterns is truly awesome.

The first half of the book is a discussion of enterprise architecture in general. I particularly enjoyed the section 'Layering' and 'Organizing Domain Logic'. I could really relate to these discussions, and much of what is written relates to problems I face often in designing my applications.

I now have a much better understanding of what a true OO Domain model should look like, and I feel more comfortable in designing a fully OO business model.

Some of the patterns presented in relation to database mapping may not be so useful because there are a lot of OR mapping frameworks available to do this for us now. But I still find these patterns useful in understanding how to use an OR mapping framework correctly and how they work under the covers. And you may not always have access to such a framework.

I found the discussions on concurrency and transactions very valuable. I also think that the presentation patterns section is quite good too, although again there are a lot of presentation frameworks/tools available for this kink of thing like struts, webwork/velocity, asp.net etc.

The only thing that I think this book lacks is a discussion on how to link the layers of an application together. Maybe I will read the book again soon in case I missed something, but I don't think he talks about how to integrate a domain model with the presentation layer, and he kind of skips how to integrate a domain model to the database layer (he just says use mapping which is difficult).

I am giving this book 5 stars because it will change (has changed) the way I think about designing software in much the same way that reading a book like Gang of Four.

I normally don't bother to write reviews, but some of the shallow ones I found here irritated me enough to write. I have been a developer, architect, and development manager. My latest project was a 100+ developer year enterprise application. Fowler clearly knows the field, he speaks with confidence of development experiences with projects that went live. I have no idea of what a newbie to enterprise application development would gain from this book. The DTO pattern, for example, is profoundly powerful and his representation of it is accurate, but he presents it in a casual, low-key way, and its significance might well escape the uninitiated. When you talk to programmers who only know the one thing they worked on you hear a naive, blind conviction in their voice, but when you read Fowler, you hear the weary lessons of hundreds of developers on dozens of large projects. If you are experienced, read chapter 8 first, then the patterns, then 1 - 7 if need be. If you are new, read chapter 8 first, then the patterns, then CODE the patterns a dozen times, then read the rest of the book. Fowler says you should read 1-8 then the patterns as needed, but I say the 8 pages of chapter 8 roll up the first seven chapters very nicely, and then please read all the patterns in associative order from your point of view.

I'm surprised to see here that the first edition, which I just finished reading after letting it collect dust for several years, is still the current edition on the market. Seven years in the software development industry is a long time, and I feel that this book could use some refactoring. (I couldn't resist.) For example, the book refers to a "Plugin" pattern because "dependency injection," an industry-wide practice of decoupling interfaces from implementations and configuring them at runtime, hadn't become a common term at the time the book was written. The "service stub" pattern, one of whose benefits is described as enhanced testing, is now better known as mock objects, and this book doesn't mention the tools and libraries that have sprung up around generating mock objects to facilitate more insular unit testing. Finally, when discussing object-to-relational-database mapping patterns, the book makes recommendations about "buying" one but makes no mention of solid open source solutions available like Hibernate.

The book's loosely edited style and almost chatty, informal delivery prevents it from attaining the academic perfection that the original "instant classic" Gang of Four design patterns book earned. There is frequent phrasing like "my preference," "here at ThoughtWorks," and (my favorite) "at the moment I don't have a strong opinion either way." Martin Fowler is cool, and is a renowned software personality, which makes it easy to tolerate the familiarity, but at times I wished for slightly more rigorous editing.

The book's examples are a blend of Java and C#, and while this works fairly well to present a language-agnostic view of the patterns, this book doesn't avoid an occasional platform-specific side trail (like the judicious use of Enterprise Javabeans vs. plain Java objects). This sort of indiscretion has often marred patterns books that would otherwise have achieved more timelessness (for example, the book "Pattern Hatching," a followup to the classic Design Patterns books, spent an entire thick middle chapter dealing with workarounds to problems that occur only in C++).

Some of the patterns in this book would not have been hard to come up with: if you've built a vertical slice of a multitier enterprise application, you've almost certainly developed some of these patterns on your own. The value of patterns literature, of course, is in how it increases our shared design vocabulary, and to the extent that it helps us know what we mean when someone talks about "doing it with a Table Data Gateway," this book is a worthy addition to the literature. Overall, though, for me the book was less a series of profound "aha!" experiences and more of a catalog of "so that's what that's called" moments. A decent effort, but the new reader should be aware that it would benefit from some updates.

This book is the masterpiece. This book is full of sound advice, tips and traps. The patterns in this book they are very well identified, specified, clarified, and classified. Martin brings the patterns to life with just the right mixture of prose and code.
He provides a lot of code samples. If you have really complex business logic, you will find how the patterns presented in this book are useful.

This book is useful for both J2EE and NET developers. This is particularly useful when attempting to gain an understanding of how application architectures differ between .NET and J2EE.

Domain logic patterns described in this book are very interesting, they help you to map domain logic to a design; Data source architectural patterns can be considered as extension of entity bean and DAO; object-relational structural patterns can help you to map object to table design; there are other interesting patterns as Unit of Work (in Object-Relational Behavioral Patterns) and Query Object (in Object-Relational Metadata Mapping Patterns). In a whole, you see all of the basic patterns of object-relational mapping in this book.

This book also presents some interesting presentation patterns, besides those presented in Core J2EE patterns, you can find Application Controller, Transform View, Two Step Views patterns very useful also.

There are others very useful concurrency patterns, session state patterns, distribution patterns presented in the book, and you can find some "Base Patterns", which can be considered "classical" patterns.

Martin has successfully shown how to use patterns to link together all of the parts of an enterprise system.

Just as Design Patterns did seven years ago, this book will become the basis of a vocabulary that we will use from now on to speak about information system's architecture. This book will be a handbook of many developers.

The Kindle Edition does NOT include any figures or diagrams. Quite an unpleasant surprise when reading passages like "The easiest way to see the difference is to look at the sequence diagrams for the two approaches (Figures 2.1 and 2.2).", clicking on those links and only finding a bare caption with no figure whatsoever. I contacted Amazon's customer service about this, and they replied with a mere "Occasionally, conversion to digital requires modification of content, layout, or format, including the omission of some images and tables". It would be great if Amazon worked together with the publishers to make it clear when there is missing content somewhere in its product page. Paying almost the price of the hardcover to end up with an incomplete product is unfair to say the least, and overall a bad experience for the reader.

UPDATE:
As of May 3, 2011, the issue with the missing figures/diagrams seems to be fixed.