Rating: 
Summary: Indispensable for anyone doing object-oriented analysis.
Review: For me, this is the companion volume to "Design Patterns"
by Gamma et. al. (Design Patterns picks up where Analysis Patterns leaves off). Fowler's models distill years of experience as an analysist in a wide variety of complex domains. I especially like the way he develops his models in stages, repeating the intellectual process he and his colleagues had gone through on a real project.
Rating:
Summary: Study, don't just read this book.
Review: I bet you are an object oriented software developer striving to build better applications. If you have not read GoF <i>Design Patterns</i> and followed that with Vlissides's <i>Pattern Hatching</i>, read those first. Follow those with this, Martin Fowler's <i>Analysis Patterns</i>.As two readings of <i>Design Patterns</i> took my OO knowledge from infancy to adolecence, <i>Analysis Patterns</i> will take you from adolecence to adulthood. Fowler's work does not put together patterns from the <i>Design Patterns</i> book, but takes its time to decompose actual application domain concepts to applicable object models. It will then be up to you to use your knowledge from <i>Design Patterns</i> to create mechanisms that support properly modeled business concepts as <i>Analysis Patterns</i> describes. If you like OO modeling and design, but are wondering how better to apply your modeling concepts, Fowler's book is something you will definitely benefit from. However, make a pot of coffee per chapter-this book is very dense with concepts. Fowler ends <i>Analysis Patterns</i> with some more easily read chapters on application design on a larger scale. You've heard of "n-tier," his discussion of the concepts of "n-tier" at the end of the book are possibly worth reading first. After reading this book-and understanding it's motivations-you will never again be tempted to take "innocent" shortcuts in your application design. You will not be motivated to use "Strings" for "measurements" or "doubles" for "distances." You will look upon your peer's object designs either with a new understanding that they know that going the distance with their object model is worth it-and you won't demand they dumb down their design ever again-and you'll likewise gain intuition about where a simplistic business domain model is going to fail.
Rating:
Summary: Study, don't just read this book.
Review: I bet you are an object oriented software developer striving to build better applications. If you have not read GoF Design Patterns and followed that with Vlissides's Pattern Hatching, read those first. Follow those with this, Martin Fowler's Analysis Patterns. As two readings of Design Patterns took my OO knowledge from infancy to adolecence, Analysis Patterns will take you from adolecence to adulthood. Fowler's work does not put together patterns from the Design Patterns book, but takes its time to decompose actual application domain concepts to applicable object models. It will then be up to you to use your knowledge from Design Patterns to create mechanisms that support properly modeled business concepts as Analysis Patterns describes. If you like OO modeling and design, but are wondering how better to apply your modeling concepts, Fowler's book is something you will definitely benefit from. However, make a pot of coffee per chapter-this book is very dense with concepts. Fowler ends Analysis Patterns with some more easily read chapters on application design on a larger scale. You've heard of "n-tier," his discussion of the concepts of "n-tier" at the end of the book are possibly worth reading first. After reading this book-and understanding it's motivations-you will never again be tempted to take "innocent" shortcuts in your application design. You will not be motivated to use "Strings" for "measurements" or "doubles" for "distances." You will look upon your peer's object designs either with a new understanding that they know that going the distance with their object model is worth it-and you won't demand they dumb down their design ever again-and you'll likewise gain intuition about where a simplistic business domain model is going to fail.
Rating: 
Summary: Swimming through mud.
Review: I found this book very hard to work with. I'm convinced that the book's models and ideas have merit once they can be understood but getting that level of understanding is being very difficult. I've had colleagues also attempt to get to grips with this book to see if was just me, but all of us have had the same problem. This book explains scenarios at a reasonably understandable level for each of the examples and then dives very quickly into the abstract without a clear path of how things relate to the original problems. Other issues were the use of smalltalk for examples (smalltalk may be a fine language, but it's hardly intuitive for c,java or vb programmers), and the decision not to use UML for diagrams.
Rating:
Summary: Superb, but abstract. Concise, detailed and highly valuable
Review: I really do like Martin Fowlers books. He is bright, clear, rigorous and relevant. This is his first book and most difficult to grasp book. I started reading it a few years ago and had to give up: it was too abstract for me to grasp. Now with a few more years of OO and pattern experience it shines at me in all its beauty.
This book condenses so much Analysis/Architecture/Modeling knowledge that it is difficult to come up with an idea to tackle the abstraction problem. Examples might help but how many does one need. I guess far too many.
Still I have a wish: Please write a new edition with UML diagrams and sample code in JAVA.
Then I also do have a big wish: I want more of this topic.
Rating:
Summary: indispensable for those using OO analysis
Review: I've got most of the books on patterns and find that this is the one I use the most. The writing is clear, the patterns address problems that I run into, and mostly the solutions are just what I need. This book is great to give to analysts who are having trouble agreeing with each other, because they often are persuaded by the book. It is great to give to analysts who are trying to master OO concepts, or to programmers who don't understand why things have to be so complicated. Everybody I know who has read it likes it. I just wish more people would read it! The only thing I don't like about the book is the notation. I wish he had used UML. On the other hand, after you spend a few days with it, it isn't hard to understand. It is just one more notation.
Rating: 
Summary: If convert to UML, all the relations are association.
Review: If one convert the author's pattern diagram to UML (the standard in industry), he/she will find that all the diagrams in the book are actually "association" relationship. There are no inheritance, no containment, no navigation in his patterns. It looks boring since only "association" relations were used. Probably that is why the author did not draw the diagram with UML, although he said he wanted to.
Rating:
Summary: Truly Unique, Extremely Valuable Entry
Review: Kind of funny, reading the reviews here makes it clear that this book is something of a sleeper, it has not gotten the exposure that a lot of the other pillars of the pattern community have. I think the reason is that people may glance at it and think that it is too domain-specific. In fact, this book does a lot of great things, it is a meditation on some crucial OO modeling issues. The first problem Fowler broaches is a patient's weight and he states, correctly I'm sure, that most programmers would just make weight a class property and make it be of type integer. But there are problems with that approach. First one is the issue of units. If you make it an int you are assuming that it is just a count of pounds. What happens if you want another measure? Furthermore, what happens when someone asks where the patient's weight has gone in the last month. From this point of departure, many issues are taken up. For people who have grappled with OLAP before and know something about dimensional models, it will seem as though he is trying to make an operational into an analytical model, which experience has taught us is not good. But, in fact, there is sanity to Fowler's approach. Personally, if he ever does rev this book (read on his site that he is thinking about it), I wish he would consider writing a section that attempts to hide the observation elements and seamlessly map them back into the object model. Having a separate class keeping track of what the weight of a person represented by another class is does ultimately seem to undo the objectness of the model, but that's a minor nit. Definitely a book that I've returned to many times.
Rating:
Summary: Strong advocate for the domain analyst
Review: The analysis model is often forgotten. Too often designers will do just that -- design, i.e., solve the problem before serious inquiry into requirements analysis. This book addresses that which is between the use-case and detailed design model. It is the domain analysis model. Fowler is an excellent student of M. Odell, and it's high time that Odell's thinking was made accessible to the domain analyst. Fowler's book is general enough to get across the point that it is how we think about the problem that is the important part of modeling, and not some arcane "modelling process" that is significant to methodologists. A note about reusability, as pertains the title: to my mind it is this thinking which Fowler describes that is a part of modelling that is reusable. The output of his thinking, the actual models in his examples deriving largely from the financial domain, could be in fact reused. But it is the thinking that is important. The only bad thing I can say about this book is that I fear, by its title, it may not reach its desired audience of the domain analyst, because these are, quite frankly, the scientist, the doctor, the finance expert, etc. that can really benefit from modelling since they have the in-depth knowledge of the domain. It is the job of whoever reads this book to spread the message. Power to the domain analyst
Rating:
Summary: A bit too abstract
Review: There are lots of interesting ideas here, but the actual patterns themselves are not that useful as they are too abstract.
| 
