What do you think?
Rate this book
Analysis Patterns: Reusable Object Models
Martin Fowler is a consultant specializing in object-oriented analysis and design. This book presents and discusses a number of object models derived from various problem domains. All patterns and models presented have been derived from the author's own consulting work and are based on real business cases.
357 pages, Hardcover
First published October 19, 1996
50 people are currently reading
1004 people want to read
About the author
Martin Fowler
47 books1,110 followersMartin Fowler (b. 1963) is a software engineer, Chief Scientist at ThoughtWorks, and an outspoken advocate for best practices in enterprise software design, particularly in regard to agile software development methodologies, including extreme programming.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 13 of 13 reviews
October 19, 2014
the majority of this book is devoted to discussing analysis patterns for specific contexts - e.g., what might we use as a design for a system that needs to be able to manage accounts, convert between currencies, etc. this seems like an extension of the "reusability myth" - now that we're doing object oriented programming, we can reuse our objects all over the place, and consequently have to write less code. this kind of reuse has been shown to work in two limited contexts: libraries and frameworks. code reuse is harder than it seems as the objects need to interact with other parts of a specialized system, and each system has its own special needs. it would be easier to reuse the design rather than the code, and that's Fowler's basic idea here. all the same, when designing a new system, I would want to focus my analysis on the specific needs of that system. I could see, e.g., skimming the section on currency conversions in this book of I was designing an app that needed to do currency conversions, to maybe get some ideas. but my hunch is that I would come up with a decent design based solely on the qualities of the specific system being designed.
the remainder of the book is on support patterns, or patterns in implementing a design into software. the presentation on three-tier architecture gives an interesting precursor to the idea developed by Eric Evans in Domain Driven Design. most of the remainder deals with implementation issues relating to rather old-fashioned OO programming languages.
like many software books, this text had not aged well. the biggest thing I got out of skimming through these analysis patterns was the impression that UML was not a very suitable tool for this kind of work, and in some ways quite OO-specific. many implementation concerns addressed are non-issues in modern languages such as Scala. a lot of the underlying landscape idea-wise has changed as well with concepts like DDD and event sourcing. more than anything else, this book helped me so appreciate programming in a language like Scala rather than a language like Java or C++.
the remainder of the book is on support patterns, or patterns in implementing a design into software. the presentation on three-tier architecture gives an interesting precursor to the idea developed by Eric Evans in Domain Driven Design. most of the remainder deals with implementation issues relating to rather old-fashioned OO programming languages.
like many software books, this text had not aged well. the biggest thing I got out of skimming through these analysis patterns was the impression that UML was not a very suitable tool for this kind of work, and in some ways quite OO-specific. many implementation concerns addressed are non-issues in modern languages such as Scala. a lot of the underlying landscape idea-wise has changed as well with concepts like DDD and event sourcing. more than anything else, this book helped me so appreciate programming in a language like Scala rather than a language like Java or C++.
July 10, 2020
Edit:
After skimming other reviews, I felt the need to add my professional context. I work as software developer and consultant in the heavy indsutry. Software is not "our" speciality, but we need it to survive. As such, I'm often confronted with tasks like digitalizing business processes that don't even exist in the heads of those who perform them, or literally don't exist because they are part of the change management agenda, who happily use software as their beast of burden.
Since I'm not a domain expert myself, yet need to figure out what it is they are doing and needing - while communications are restricted, and legacy artefacts or even systems are everpresent - I need an abstract view-point from where to analyse and probe their concepts.
Where this book, and most others of this genre I review, come into play:
This book is exactly what it claims to be: A toolbox for analysing processes.
It does not promise to solve your problems, or give you a guide to how to analyse them and design solutions based on your analysis. Instead, it offers you profound models and patterns, based on real life cases, which describe abstract scenarios which on their level of abstraction, or a higher one, might be useful for your specific case.
As that, it provides a rich collection of such utility tools. As an analyst working part in software-engineer, part in business model reengineering, it happens there are mostly two chapters in this book I really use over and over. The patterns help me design how I question customers, where to look for the needle in the hay, or how to explain a solution to a domain expert.
Thus they are more like a compass, a map for the lost, to help reorienting oneself in the complexities of real life and processes.
In that regard it does a perfect job. I hope that one day it will be a common sight that senior analysts share the models from their life with the rest of the world, so that others may collect them - like explorers of the unknown would collect maps, descriptions and journals of other explorers before them.
After skimming other reviews, I felt the need to add my professional context. I work as software developer and consultant in the heavy indsutry. Software is not "our" speciality, but we need it to survive. As such, I'm often confronted with tasks like digitalizing business processes that don't even exist in the heads of those who perform them, or literally don't exist because they are part of the change management agenda, who happily use software as their beast of burden.
Since I'm not a domain expert myself, yet need to figure out what it is they are doing and needing - while communications are restricted, and legacy artefacts or even systems are everpresent - I need an abstract view-point from where to analyse and probe their concepts.
Where this book, and most others of this genre I review, come into play:
This book is exactly what it claims to be: A toolbox for analysing processes.
It does not promise to solve your problems, or give you a guide to how to analyse them and design solutions based on your analysis. Instead, it offers you profound models and patterns, based on real life cases, which describe abstract scenarios which on their level of abstraction, or a higher one, might be useful for your specific case.
As that, it provides a rich collection of such utility tools. As an analyst working part in software-engineer, part in business model reengineering, it happens there are mostly two chapters in this book I really use over and over. The patterns help me design how I question customers, where to look for the needle in the hay, or how to explain a solution to a domain expert.
Thus they are more like a compass, a map for the lost, to help reorienting oneself in the complexities of real life and processes.
In that regard it does a perfect job. I hope that one day it will be a common sight that senior analysts share the models from their life with the rest of the world, so that others may collect them - like explorers of the unknown would collect maps, descriptions and journals of other explorers before them.
July 19, 2018
Good but outdated
This book was great at a time writing. It is less useful now. It still contains many valuable pieces about OO modeling, but reader should not hesitate to skip over some chapters.
This book was great at a time writing. It is less useful now. It still contains many valuable pieces about OO modeling, but reader should not hesitate to skip over some chapters.
August 15, 2019
The book is good, but I have mixed feelings about it.
From one side, it has some very good conceptual models.
From the other side, it is a bit outdated and the prose is somewhat a bit heavy.
Anyway, a good addition to your conceptual toolbox.
From one side, it has some very good conceptual models.
From the other side, it is a bit outdated and the prose is somewhat a bit heavy.
Anyway, a good addition to your conceptual toolbox.
April 17, 2019
I've read just some chapters that was of interest for me. I was interested in understanding the "Accountability Pattern" and Martin Fowler explains it in depth with a lot of details. Also he presents a natural evolution path of the "Accountability Pattern" from the most understandable and applicable form to a very complex form of the pattern that is applicable only in large enterprises with complex systems and models. I will come back at this book anytime I will need to understand a pattern or anytime I will need to create a model based on a specific pattern.
March 19, 2020
Analysis patterns in object models by Martin Fowler.
March 22, 2021
For sure this is a decent book. But I don't think it worth reading it in 2021 unless you are interested in patterns history.
February 17, 2016
Takes you through the thought process of developing some generic object models for common business-domain problems.
Some good discussion about how to model and implement these, hampered by the notation of the (pre-UML) modelling diagrams.
I also found it a bit dull, to be honest - not up to the standard of his other, more recent, books
Some good discussion about how to model and implement these, hampered by the notation of the (pre-UML) modelling diagrams.
I also found it a bit dull, to be honest - not up to the standard of his other, more recent, books
January 13, 2014
The patterns in the book are very high level and hard to understand on the first attempt. One probably needs considerable experience in developing big systems to read and understand the book.
Also, the pre-UML models are confusing at the beginning.
Also, the pre-UML models are confusing at the beginning.
June 9, 2015
1 of the classic software texts on analysis and design.
May 26, 2014
Simply a must-read for any developer, dev lead, and even IT managers.
October 8, 2014
A nice collection of patterns for use in designing enterprise software systems.
Read
January 10, 2019This book can be a good additional to Domain-Driven Design. Analysis Patterns is a listing of domain model skeletons for enterprise applications.
Displaying 1 - 13 of 13 reviews