For me, this book is an invaluable reference for building business apps.

Want help choosing a framework? Want some guidance for solving common business problems? These patterns help solve these kinds of problems.

NOTE: I have tried to find other sources for these patterns, and I have only found Fowlers website, which is really only a summary and recommends purchasing the book.

This book has examples in both Java and C#. You can certainly use these patterns in .NET.

Under .NET you are not actually forced to use the Table Model. I think the purpose of this book is to help you realize this.

There are frameworks for .NET that use the Domain Model and Data Mapper patterns, but you would never know this unless you were familiar with the patterns in this book.

For me, reading this book didn't allow me to write new code, but it did allow me to understand my choice to use a particular framework/technique over another.

As a newcomer to enterprise architecture this book educated me on possibilities for decisions to be made in designing an enterprise architect. It will also give you a language for describing existing characteristics of an existing enterprise application which may use some combination of the patterns describe in this book. The discussion of where to keep session state for a webapp was particularly helpful to me.

I haven't been able to read it cover to cover, but i read the mapping chapter and it was good. Explain a complex subject in relly simple way.

Also the hard cover is nice!

Even if you find enterprise stuff immensely dull, dealing with databases and web pages is a pretty common task, most of the action in software development revolves around it, and who wants to be completely ignorant of the the alphabet soup of various technologies the IT blogs, books and websites are floating in?

So if you must immerse yourself in this area, what better than a Martin Fowler book? The code is mainly in Java, with a fairly large smattering of C#. It would probably help if you understood some basics of enterprise development in those languages, e.g. servlets and JDBC for Java.

The patterns in this book cover organising domain logic, database mapping and access, web presentation, concurrency, and the book finishes by covering base patterns, a mixture of lower level abstractions of the sort covered in Fowler's first book, Analysis Patterns (e.g. Money), and those that bear a close resemblance to the classic Gang of Four patterns, with an enterprise twist (e.g. Plugin and Gateway). Nearly all the other patterns refer to these, so I don't know why these didn't appear first. Apart from that though, the book is very well organised. And the opening essay, that discusses the trade offs of every pattern and how they fit together in an application, is immensely helpful.

Wizened enterprisers looking for new material will not find much new here, but surely the point of patterns catalogues are to get down on paper the practices of those same wizened enterprisers, not to strike off in new directions. Therefore, an experienced developer should see this as a way to organise what they already know, and maybe in doing so, reveal some new insights.

A newcomer to enterprise development will definitely get a lot out of this, as the underpinnings to the plethora of modern enterprise applications are laid bare. You're not going to become a Hibernate, Struts or EJB expert from this book, but you should at least have a clue about what problems they're trying to solve.

As usual, Fowler manages to be a model of clarity, while still injecting regular touches of wry humour, quite an achievement given the potentially bone-dry material. If you want to know the basics of enterprise software, start here.

Martin Fowler is making a name for himself as a luminary in the area of Software Development. He writes very practical books that have a wonderful blend of theory (e.g. design patterns, UML, refactoring etc.) with experience as you can tell he has applied many if not all of these patterns in real-life projects. This book is an exposition into architectural building blocks that will help every architect and tech lead / senior developer build code that is more extensible and easily maintained (among other things). I found the chapters on O/R structural and behavioral patterns particularly enlightening. By reading this book your "toolbox" of solutions rapidly expands and you get to focus more on the business problem at hand rather than infrastructural "plumbing" things (e.g. how do I build my objects when my data is in a relational table). Very highly recommended - and definitely one of the top 5 software books I have *EVER* had the pleasure to read.

I loved this book! It was exactly what I was looking for when I went searching for patterns that would help with a new business application. It provides alternative solutions to the typical implementation problems associated with business systems, both from a design standpoint and from the perspective of the implementation. The alternatives are compared and weighed in light of the execution environment and cost of implementation, with a comparison of advantages and disadvantages, along with Martin's recommendations. I had the feeling that the comparisons and recommendations were made not based purely upon a theoretical optimum, but also based upon practical and real-world experience with these patterns.

If you are already well-versed in architectural patterns, you probably won't find much to interest you here. But if you are new to the subject, this is a great book. It goes beyond design patterns to show how to combine and implement the patterns in the real world. In particular, the 100-page tutorial that starts the book is a great intro to the subject.

If I had to recommend two books to someone wanting to learn OOP, I'd recommend 'Head First Design Patterns', then this book.

Another great pattern which is absolutely benefitial to large-scale enterprise development. The enriched and practical content provides a framework-level design skeletion and references for architects and developers to study and apply. Patterns like Domain Model, Data Mapper, Unit of Work, Identity Map, (Single/Class/Concrete) Table Inheritance, Layer Supertype, Value Object etc are nowadays most popular in the software design or even in framework design(e.g. J2EE/.NET) that can use any language to implement(C++/Java etc).

The reason I am so positive about this book is that it has created a common language for Enterprise Architects. When I say 'DTO' people know know what I mean. That is the real value, that Mr. Fowler took the time to catalog and NAME these practices and challenges we face every day. The real point here is the bandwidth of your team communications can be greatly enhanced as you can refer to the named abstractions instead of spending the time describing them.

Kind Regards,
Damon Carr, CEO
agilefactor
www.agilefactor.com

As said in the review title, I consider this book a "must" for software architects. Well written and easy to read... A great job!

As a software developer, the problem space for an application is quite different in the Enterprise than it is for a small domain. This being stated (and is in the book), Mr. Fowler quickly points us to effective patterns to be used for developing enterprise applications. Like the Gang of Four book, this book is a catalog and a good description of the patterns to be used in this space. Mr. Fowler has long been a guru in software engineering and this book clearly shows why. The text is very well written, easy to follow, and indicative of someone who knows what they are talking about, not only from a clear thought process, but from experience as well. This should clearly be a book that sits along with the Gang of Four book on your shelf (Design Patterns) for the Enterprise developer or someone interested in enterprise development.

I enjoyed this book very much. Martin Fowler's writing style makes reading about patterns as fun as it should be. He correctly points out that this book is not intended to give experienced developers a lot of new ideas, but rather to give names to patterns we have all been using for a long time. That's the great benefit of the book, it gives us a vocabulary we can use to talk about these things without spending tons of time explaining what we mean. I recommend it highly.

Probably the best general application architecture books out there. The only time this book gets specific to a proprietary technology is in the examples only because martin wants to show you a real world example of what he is talking about. There are examples in C#, some in java, etc. It is organized very well and if you were around when he was developing it you could have gotten the whole book in pdf form for free!

You could view this as a rehashing of patterns that have existing for some time - or - you could view this is a collection of those patterns that are still relevant today. Based on how I used this book in my work, I see it from the latter perspective. There's nothing wrong with re-documenting old material when you focus on what's been proven and successful. Plus, there's new content that will be of interest to many as well. Though this book came out a while ago, I feel it is still relevant today.

I read this the first week it came out and was suprised by how much it rehashed GOF and the Core J2EE patterns books; however I have referred back to it on "Unit of Work" and a couple other concepts that it helped to differentiate. TO it's credit it consolidated information from several bodies of knowledge in patterns, and it provided c# examples in many cases, thereby being the first high profile work that really exposed MS developers to a world of patterns, that was arguably previously unknown. Besides being somewhat lacking in originality, the other problems were the fact it actually catalogued anti-patterns as patterns (e.g. transaction script is basically unmaintainable web pages), and it addressed enterprise system architecture without paying any mind to integration concerns (see Hohpe for an excellent treatment of this subject); I'm not sure the two really are separable when we start talking about business services. The best thing about this book is that it emphasizes the criticality of rich domain models in complex systems, which IMHO is a core design principle which is currently being eroded by a current of irrational and marketing-drunk SOA furor ... which reminds me, Domain Driven Design is not to be missed, it's simply an inspired work which helps to make Fowler's domain model achievable for almost anyone.

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.

This book is a little more implementation specific than the incredibly popular Gang of Four Design Patterns book. Many of the patterns, the Data Transfer Object pattern, for example, are fairly specific to the J2EE structural problem at hand. Other patterns, like the Lazy Load, are good architectural patterns on any platform. There is enough generic content to justify the purchase of the book for architects implementing on any platform (J2EE, .NET, PHP, etc.) but it does favor the two current platforms de jour; J2EE and .NET.

One of the nice things about the book is how the code tends to de-emphasize the application container by doing most of the work in the raw database access systems (e.g. JDBC), which makes it easy to understand what is going on but will offend the true J2EE believer. This makes the patterns in the book accessible to anyone coding in any environment, which I greatly appreciate.

One pet peeve is that some of the patterns are obvious shells for a single technique, such as the Transform View, which is really just XSLT. The text says as much, but shouldn't there be more than one example of a particular pattern in nature? It's just a pet peeve though, it's no reason to avoid the book.

Overall, the book is well written and edited and the graphics add to the exposition but are not gratuitous. It's a useful guide for anyone looking to raise the level of the enterprise application (read web application) thought up to the next level.

Martin Fowler is a brand name for lucid ("UML distilled"), maturity enhancing ("Refactoring" for the practical side and the great "Analysis Patterns" for the modeling side) top notch books for software professionals. This book even has on its front cover a label telling us it is a "Martin Fowler Signature Book". This book was a disappointment. In the introduction Fowler claims much less. This book should be merely "useful". It is much better than that. It is good.

So what is the problem? The title is misleading. It is about patterns, but not really about enterprise applications. I am not in the subject of enterprise applications. I never ever have touched a program like SAP or a language like COBOL. But I encountered nearly every problem addressed in the patterns. Even the money class has corresponding problems in other fields: a Voltage has both a value and a unit. Also having complaints about the fact that 3 times 33% are less than 100% are always common.

What is this book about? It is basically about problems you have in moderately big applications. How do you connect a relational database with its structure and transactionality to a system, especially an object-oriented system (but not only)? And how do you connect to the user interface, especially a web interface. Also it contains a lot of useful small patterns at the end. As you can see: a lot of valuable stuff for many people. Yes and you get the deep judgments and fine humor of Martin Fowler too.

What is the main problem? This book is not really suited for actual reading. It contains an introductory part of a hundred and a reference part of four hundred pages. The introduction part is annoying to read. It is at the same time too simple (Some knowledge of relational databases should be a requirement for this book, and much more...) and too difficult (An extremely lot of forward references to patterns described later in this book). Also a lot of stuff is in the most trivial sense repeated within a few pages distance only. And it is repeated down to the wording of the individual sentences.

The reference part is a lot better. It gets better to read the further along you already read. The number of forward references gets less along the way. I liked especially the last part about base patterns. As their name already says they should have been much more to the beginning of the book.

This book contains an excellent book within it, just waiting to be "refactored" out of this collection of valuable thoughts. I firmly believe that Martin Fowler is well suited to do this refactoring job. I do sincerely hope that he does it for the next edition of the book. Most of the work is already invested and the result would be very valuable for many people. It is possible to write excellent and readable books about patterns as for example Buschmann et al in "Pattern Oriented Software Architecture" showed.

If you've read Refactoring or UML Distilled, or Planning XP, you won't be disappointed with this Fowler book. He's the clearest writer and thinker in the Agile/XP/Patterns group of authors.

The book is particularly strong in describing how to map between a persistent relational database and an in-memory object representation of business logic. Fowler distills the various approaches to their essence, clearly presents the tradeoffs and defines an intuitive vocabulary to make it easier for development teams to discuss how the patterns apply to their unique application.

Highly recommended.

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.

Overall, I was disappointed by this book. I develop business applications, and I was hoping this book would provide practical insights about such applications, more specifically in the database/web realm. While this book does contain some interesting pieces of information, it really is not of immense value to a developer such as myself. Here's why:

This book is a bit of a mishmash of different topics, but the vast majority of it (I'd say 75% or more) consists of ideas for object-relational mapping. Since most developers would use existing tools for object-relational mapping (in the Java realm, see Hibernate, JDO, etc.), I fail to see the real usefulness of this book for most developers building business (web) apps. Further, this kind of book encourages people who don't have the necessary expertise to try rolling their own OR mappers, which is simply not a good idea.

It's too bad, because the book starts off promisingly enough with 3 general approaches to business apps: Transaction Script: The procedural/transactional approach; Domain Model: The OO approach; and Table Module: The data-cetric approach. So far so good. Unfortunately the book then seems to steer off to the topic of "Fun With OR Mapping." It's not as sexy, but I think that's perhaps what the title of this book should have really been! The book then goes on to talk about different ways to architect Web applications, again mostly getting into how to develop framework code, which one largely would take for granted if one is deciding which framework to use rather than rolling one's own. Finally the book talks a bit about locking strategies (pessimistic, optimistic) and then presents a few generic items (e.g. the concept of a Money class or a Registry class).

Only a very small fraction of this book will be useful to a non-framework developer. Also, even though this book claims to be technology-agnostic, it seems rather firmly planted in the Java world. I'm not convinced an ASP/ADO.NET developer would find it particularly useful, for example. I think there is an important need to demonstrate how to put together solid business applications. I'd love to see a book of recipes that says "here's how to develop an ASP/ADO.NET app; here's how to develop using EJB; here's how to develop using Hibernate..." but without all the distracting details of how to implement the whole solution from scratch -- Basically I want a book that relies on the idea that frameworks are out there, but focuses the developer on how to choose a framework and how to take advantage of frameworks to produce solid, maintainable solutions.

Lastly, I would say Core J2EE Patterns from Sun Press is a more useful book for the Java/J2EE crowd, though it too suffers from framework-itis.

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.

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 a well written book, with resonable explanations and samples. If you are familiar with patterns by GOF and distrubuted architecture patterns then there is not much new in this book. If not this is a must read and serves as a basis for platform independant review of a good cross section patterns to be applied in enterprise architecture, in which RDBMS's are always a key component. My expectations were high based on Mr Fowlers earlier works, not to say this is a lesser work, just it has been well covered before this work by Mr Fowler.

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.

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

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.

This is an excellent Patterns book for a mature audience, and is a must-have for software architects and designers. In my opinion, together with the GOF's "Design Patterns", it stands out of the rest of the Patterns books, primarily because the patterns are real and are very clearly presented.

A reader with a moderate experience architecting and designing industrial strength software systems will find at least some of the patterns familiar. You may actually enjoy reading this sort of patterns even more than those that are new to you: finding the validation of your own observations and ideas, as well as learning about new flavors and variations from the experience of others, can be a very satisfying process.

The book consist of two parts: The Narratives and The Patterns. The first part describes architectural patterns in general, their relationships, and the problems they help to solve. Here you will find chapters about layering, organization of domain logic, object-relational mapping, web presentation, system distribution strategies, etc. The second part is a collection of patterns with a similar organization.

Both parts of the book are written in a simple and clear narrative language. To get most value out of the book requires fluency in the UML; practically anyone with an object-oriented programming language experience will understand illustrative code snippets.

In short: if you want to learn the wealth of architectural ideas compiled by the experts from the real-world experience and not get bored along the way -- get this book.

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.

Martin Fowler is a great speaker and presenter. I felt this book felt short of his image and wasn't all that good. If Martin were not the author of this book, I suspect that it would not have sold any copies.

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.

This is certainly a very good reading about building enterprise applications. I like that the author gives samples for the most currently used software platforms, such as Java and .NET. Anyway, the author treats more the specifics of Java than those of .NET, and that shows the patterns he discusses don't always have such a general applicability. A certain thing not well covered is related to the table module. I have a compelling question about it and if any readers of the book are willing to help me with that, please let me know. I suppose questions aren't to be posted in a book review.
To conclude, I liked reading the book and I'm sure it's worth the money.

Martin Fowler does it again. He manages to capture complexities of enterprise class application development in a simple, easy to read book.

If you've read any of Fowler's other titles, the structure of this one will come as no surprise. The first have of the book discusses the patterns in "narrative" format, and the second half presents them in reference format. If you are new to this subject, I highly recommend reading through the narrative section to understand how the patterns fit together.

If you've been involved in enterprise application development before, chances are you can simply flip to the second half of the book and start skimming the patterns. Each is only a handful of pages long and is accompanied by a description, use cases and example code.

Like other "patterns" titles, if you've been doing software development for a while you'll read the patterns and think "oh.. of course, I did that in xyz project". The patterns themselves may not be groundbreaking and chances are you've seen them in some form, but having a well documented reference of them nearby will be an asset to any software development effort.

There is a good reason why this book scored 10/10 in a Slashdot review. Fowler writes with such clarity and organization that even the most complex enterprise architecture concepts are handily broken apart into manageable chunks (patterns). For instance, Fowler attacks the challenge of object-to-relational data mapping by breaking it into architecture, behavior, structure, and metadata patterns. The result is a set of clearly defined, vendor-neutral, "concept tools" that the reader really knows when to use. This book is to enterprise app design what the classic Gang-of-Four book is to OO design.

I'm a little surprised by the number of rave reviews about this book. The book is ok, but there are some annoying problems that let it down. For starters, the lack of decent proofreading before going to print � it�s an expensive reference book and I would expect better quality. Secondly the colloquial vernacular only impedes, not complements the reading. Thirdly, the patterns seemed fewer than I expected and covering only elementary issues. I suppose the audience is primarily for enterprise architecture novices.