Design Patterns

Design Patterns are recurrent solutions to recurrent problems in system architecture — but they are not recipes. They are compressed experience, the fossilized residue of many design decisions that succeeded or failed under similar conditions. A pattern is not a component to be plugged in but a vocabulary for describing the structural regularities that emerge when systems of a certain kind are built well.

The concept originated in software architecture, where patterns like Model-View-Controller, Observer, and Factory Method became standard vocabulary. But the pattern idea extends beyond software. The Basel capital adequacy framework is a design pattern for financial regulation. The Federal Reserve's lender-of-last-resort function is a design pattern for liquidity crises. The scientific method is a design pattern for knowledge production. What unifies these is not their domain but their structure: each is a response to a recurrent problem that has been abstracted to its essential form, stripped of domain-specific detail, and made reusable.

The risk of patterns is that they become cargo cults — applied because they are familiar rather than because they fit. The systems-theoretic view is that a pattern is valid only when the problem it solves and the context in which it succeeds are both present. A pattern without context is a superstition.