Analysis Patterns

by Martin Fowler, Ward Cunningham (Foreword), Ralph Johnson (Foreword)

Patterns are higher-order designs that can be reused across projects and types of computer systems. Analysis Patterns: Reusable Object Models defines over 70 patterns, beginning with some from the business world, such as the Party and Accountability patterns, which define the players in organizations and whom they report to. Many of the other patterns are drawn from the health care industry and mainly show patterns of doctor-patient interactions.

The patterns for financial markets will probably be accessible for the majority of readers. Author Martin Fowler defines a Transaction pattern (and related patterns) as well as several patterns for the Accounting of Objects. He moves on to modeling stock markets with Portfolio, Quote, and Scenario patterns, which define how a price for a stock is determined for a given moment. Interestingly, he establishes patterns for Forward Contracts (for derivatives) as well as Options, and so takes on a complicated area in today's financial markets.

Fowler's considerable design experience in these fields is beneficial, as he is able to define each pattern in both text and software engineering diagrams. Only rarely does the author provide implementations of these designs and those that are furnished are done in Smalltalk, which makes this book more suitable for those who have experience in object design.

Genres: Programming, Technology, Computer Science, Software, Technical, Architecture, Nonfiction

Hardcover

First published October 19, 1996

About the author

Martin 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.

Reviews

[John · Rating 3 out of 5]

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++.

[Fiona · Rating 5 out of 5]

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.

[Michael · Rating 3 out of 5]

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.

[Paolo Bizzarri · Rating 3 out of 5]

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.

[Dina Bogdan · Rating 5 out of 5]

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.

[Hania · Rating 5 out of 5]

Analysis patterns in object models by Martin Fowler.

[Pavels Kletnojs · Rating 3 out of 5]

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.

[Steve Whiting · Rating 3 out of 5]

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

[pluton · Rating 2 out of 5]

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.

[Steven · Rating 4 out of 5]

1 of the classic software texts on analysis and design.

[Juan Ignacio Gelos · Rating 5 out of 5]

Simply a must-read for any developer, dev lead, and even IT managers.

[Dave Peticolas · Rating 3 out of 5]

A nice collection of patterns for use in designing enterprise software systems.

[Eduards Sizovs]

This book can be a good additional to Domain-Driven Design. Analysis Patterns is a listing of domain model skeletons for enterprise applications.