Analysis & Design Patterns Comprehensive Guide
Analysis &
Design Patterns
Comprehensive Reference Guide
Types, Explanations, Diagrams & Flows
Creational Structural Behavioral Architectural Analysis
5 Patterns 7 Patterns 11 Patterns 4 Patterns 6 Patterns
Design Patterns Reference Guide Page 1
Analysis & Design Patterns Comprehensive Guide
Table of Contents
1 Introduction to Patterns 3
2 Analysis Patterns 4
3 Creational Design Patterns 6
4 Structural Design Patterns 8
5 Behavioral Design Patterns 10
6 Architectural Patterns 12
7 Pattern Comparison & Selection 14
8 Summary & Quick Reference 15
Design Patterns Reference Guide Page 2
Analysis & Design Patterns Comprehensive Guide
1 Introduction to Patterns
A design pattern is a general, reusable solution to a commonly occurring problem within a given context in
software design. Popularised by the Gang of Four (GoF) in 1994, patterns are not finished designs but
templates showing how to solve a problem in various situations.
Analysis patterns, introduced by Martin Fowler, focus on recurring conceptual structures found during domain
modelling — they describe how to organise domain objects before implementation decisions are made.
Pattern Categories
Category Focus Examples
Analysis Domain model Party, Accountability, Observation
Creational Object creation Factory, Builder, Singleton
Structural Composition Adapter, Decorator, Proxy
Behavioral Communication Observer, Strategy, Command
Architectural System structure MVC, Microservices, Layered
Analysis Patterns Overview
Accountability Observations
Party / Role Measurements
Analysis Patterns
Quantity Associations
Figure 1 – High-level map of Analysis Pattern groups
Design Patterns Reference Guide Page 3
Analysis & Design Patterns Comprehensive Guide
2 Analysis Patterns
Analysis patterns capture recurring concepts in business domains. They are language-agnostic and
technology-agnostic — they live at the conceptual modelling layer and help analysts produce consistent,
reusable domain models.
2.1 Accountability Pattern
Describes how a Party (person or organisation) plays a Role and takes on an Accountability. This pattern
avoids creating a separate class for every possible combination of party type and role.
1 0..* 1 0..*
plays has
Party Role Accountability
Figure 2 – Accountability chain: Party → Role → Accountability
2.2 Party / Role Pattern
Separates the notion of who (party) from what they do (role). A single party can play many roles
simultaneously; roles can change over time without changing the underlying party object.
2.3 Observation & Measurement Pattern
Models the recording of real-world phenomena. An Observation records that something happened; a
Measurement is a quantified observation that uses a standardised Protocol.
observed as measured by
Phenomenon Observation Measurement
uses
Protocol
Figure 3 – Observation/Measurement with Protocol
2.4 Quantity Pattern
Encapsulates a numeric value together with its unit. Prevents unit-mismatch bugs by making the unit an
explicit part of the object. Operations on quantities handle unit conversion automatically (e.g. adding metres to
kilometres).
Design Patterns Reference Guide Page 4
Analysis & Design Patterns Comprehensive Guide
2.5 Knowledge Level Pattern
Separates operational objects (instances that change at runtime) from knowledge-level objects (rules and
meta-information). Reduces duplication when many objects share the same behavioural rules.
2.6 Association Patterns
Pattern Description
Historic Mapping Tracks associations over time with valid periods
Posting Rules Rules that determine how journal entries are posted
Transactions Atomic units of business activity with rollback
Account Running balance with debit/credit entries
Design Patterns Reference Guide Page 5
Analysis & Design Patterns Comprehensive Guide
3 Creational Design Patterns
Creational patterns abstract the object-creation process, making systems independent of how objects are
created, composed, and represented.
CREATIONAL PATTERNS
Factory■Method Abstract■Factory Builder Prototype Singleton
Figure 4 – Five Creational Patterns at a glance
3.1 Factory Method
Defines an interface for creating an object but lets subclasses decide which class to instantiate. The creator
defers object instantiation to subclasses.
calls extends
Client Creator ConcreteCreator
creates
Product«iface» ConcreteProduct
Figure 5 – Factory Method class relationship
3.2 Abstract Factory
Intent: Provide an interface for creating families of related objects without specifying their concrete classes.
Use when a system must be independent of how its products are created, and you want to enforce that a
family of products is used together.
3.3 Builder
Design Patterns Reference Guide Page 6
Analysis & Design Patterns Comprehensive Guide
Separates the construction of a complex object from its representation so that the same construction process
can create different representations. Director orchestrates the build; ConcreteBuilder supplies the parts.
3.4 Prototype
Specifies the kinds of objects to create using a prototypical instance, and creates new objects by copying this
prototype. Useful when the cost of creating a new object from scratch is prohibitive.
3.5 Singleton
Intent: Ensure a class has only one instance, and provide a global access point to it. Caution: Singleton
introduces global state and can make testing harder. Prefer dependency injection where possible.
Design Patterns Reference Guide Page 7
Analysis & Design Patterns Comprehensive Guide
4 Structural Design Patterns
Structural patterns explain how to assemble objects and classes into larger structures, keeping them flexible
and efficient.
STRUCTURAL PATTERNS
Adapter Bridge Composite Decorator Facade
Flyweight Proxy
Figure 6 – Seven Structural Patterns overview
4.1 Adapter
Converts the interface of a class into another interface that clients expect. Enables collaboration between
incompatible interfaces. Can be implemented via class inheritance (class adapter) or composition (object
adapter).
4.2 Bridge
Decouples an abstraction from its implementation so the two can vary independently. Uses composition over
inheritance to manage variants across two dimensions.
4.3 Composite
Compose objects into tree structures to represent part-whole hierarchies. Clients treat individual objects and
compositions uniformly through the same interface. Example: File system — both File and Directory share a
common Component interface.
4.4 Decorator
Attaches additional responsibilities to an object dynamically. Provides a flexible alternative to subclassing for
extending functionality.
Design Patterns Reference Guide Page 8
Analysis & Design Patterns Comprehensive Guide
implements extends
Component«iface» ConcreteComponent Decorator
has
ConcreteDecorator
Figure 7 – Decorator wrapping a Component
4.5 Facade
Provides a simplified interface to a complex subsystem. Does not prevent clients accessing subsystem classes
directly if they need fine-grained control.
4.6 Flyweight
Uses sharing to support large numbers of fine-grained objects efficiently. Splits object state into intrinsic
(shared) and extrinsic (context-specific).
4.7 Proxy
Provides a surrogate or placeholder for another object to control access to it. Types: Virtual Proxy (lazy init),
Protection Proxy (access control), Remote Proxy (distributed objects), Cache Proxy (result caching).
Design Patterns Reference Guide Page 9
Analysis & Design Patterns Comprehensive Guide
5 Behavioral Design Patterns
Behavioral patterns characterise the ways in which classes or objects interact and distribute responsibility.
BEHAVIOURAL PATTERNS
Observer Strategy Command Iterator Template
Mediator Chain of■Resp. State Visitor Memento
Figure 8 – Ten Behavioral Patterns overview
5.1 Observer
Defines a one-to-many dependency between objects so that when one object (Subject) changes state, all
dependents (Observers) are notified and updated automatically. Foundation of event-driven and reactive
architectures.
Subject notifies → Observer«if» implements ConcreteObs
notify()
ConcreteSubj
Figure 9 – Observer notification flow
5.2 Strategy
Defines a family of algorithms, encapsulates each one, and makes them interchangeable. Lets the algorithm
vary independently from clients that use it.
Design Patterns Reference Guide Page 10
Analysis & Design Patterns Comprehensive Guide
uses →
Context Strategy«iface»
implements
implements
ConcreteStratA ConcreteStratB
Figure 10 – Strategy with two concrete strategies
5.3 Command
Encapsulates a request as an object, thereby allowing you to parameterise clients, queue or log requests, and
support undoable operations. Key roles: Command (interface), ConcreteCommand, Invoker, Receiver.
5.4 Other Behavioral Patterns
Pattern Core Idea
Iterator Sequential access to elements without exposing representation
Template Method Defines algorithm skeleton; subclasses fill in steps
Mediator Centralises complex communication between objects
Chain of Resp. Pass requests along a handler chain until one handles it
State Allows object to alter behaviour when internal state changes
Visitor Add operations to objects without modifying their classes
Memento Capture & restore object state without violating encapsulation
Interpreter Defines grammar and interpreter for a language
Design Patterns Reference Guide Page 11
Analysis & Design Patterns Comprehensive Guide
6 Architectural Patterns
Architectural patterns are high-level strategies for structuring entire systems. They operate at a coarser
granularity than GoF patterns and address concerns like scalability, maintainability, and deployment topology.
6.1 MVC – Model View Controller
Separates application into three interconnected components. Model manages data and business rules; View
renders the UI; Controller handles input and updates Model/View.
updates renders
Model View Controller
user interaction / events
Figure 11 – MVC round-trip flow
6.2 Layered (N-Tier) Architecture
Layer Responsibility Technology examples
Presentation UI / API surface React, REST, GraphQL
Business Logic Rules, workflows Services, Domain Model
Data Access DB abstraction ORM, Repository
Database Persistence PostgreSQL, MongoDB
6.3 Microservices Architecture
Structures an application as a collection of small, independently deployable services each running in its own
process. Services communicate via lightweight APIs (HTTP/REST, gRPC, messaging).
Design Patterns Reference Guide Page 12
Analysis & Design Patterns Comprehensive Guide
request routes
Client API■Gateway Service A
Database
routes
Service B
routes
Service C
Figure 12 – Microservices with API Gateway
6.4 Event-Driven Architecture (EDA)
Components: Event Producers → Event Broker (Kafka/RabbitMQ) → Event Consumers. Benefits: loose
coupling, horizontal scalability, natural audit log. Patterns within EDA: Event Sourcing, CQRS, Saga.
Design Patterns Reference Guide Page 13
Analysis & Design Patterns Comprehensive Guide
7 Pattern Comparison & Selection Guide
When to Use Which Creational Pattern
Pattern When to choose
Factory Method Single product, subclass decides which class
Abstract Fctry Families of related products, enforce consistency
Builder Complex object, step-by-step construction
Prototype Costly init, clone from existing instance
Singleton Exactly one instance needed (use sparingly)
Structural vs Behavioral Decision Matrix
Problem Pattern Category
Incompatible interfaces Adapter Structural
Extend obj at runtime Decorator Structural
Simplify complex subsystem Facade Structural
Notify dependents on change Observer Behavioral
Swap algorithm at runtime Strategy Behavioral
Undo/Redo operations Command+Memento Behavioral
Walk a tree without modifying Visitor Behavioral
Single global config object Singleton Creational
Common Anti-Patterns to Avoid
Anti-Pattern Problem Better Approach
God Object Single class knows/does too much Apply SRP, split classes
Spaghetti Code Tangled, unstructured logic Layered/MVC architecture
Golden Hammer Applying one pattern everywhere Choose pattern per problem
Anemic Model Domain objects only have data Rich domain model
Magic Numbers Unnamed constants in code Named constants/configs
Design Patterns Reference Guide Page 14
Analysis & Design Patterns Comprehensive Guide
8 Summary & Quick Reference
Complete Pattern Quick-Reference
Pattern Type Key Benefit Drawback
Factory Method Creational Extensible creation Can over-engineer
Abstract Factory Creational Product family consistency Rigid interface
Builder Creational Readable construction More boilerplate
Prototype Creational Fast cloning Deep copy complexity
Singleton Creational Controlled instance Global state risk
Adapter Structural Interface compatibility Extra layer
Bridge Structural Vary independently Increased complexity
Composite Structural Uniform tree ops Overly general design
Decorator Structural Dynamic extension Many small objects
Facade Structural Simple API to subsystem Can hide flexibility
Proxy Structural Access control/lazy init Indirection overhead
Observer Behavioral Loose coupling on events Unexpected updates
Strategy Behavioral Swap algorithms cleanly Client knows strategies
Command Behavioral Undo/queue support Proliferation of classes
Template Method Behavioral Algorithm skeleton reuse Rigid base class
State Behavioral Clean state transitions State explosion
Mediator Behavioral Centralised comms Mediator can bloat
Chain of Resp. Behavioral Flexible pipeline No guarantee of handling
Accountability Analysis Flexible role modelling Abstract at first
Observation Analysis Clean measurement model Extra classes
MVC Architectural Separation of concerns Can be over-applied
Microservices Architectural Scalability + autonomy Distributed complexity
Key Takeaway: Patterns are tools, not rules. Choose the simplest solution that solves the problem. Prefer
composition over inheritance. Programme to interfaces, not implementations. Keep high cohesion and low
coupling as your guiding principles.
Design Patterns Reference Guide Page 15
Analysis & Design Patterns Comprehensive Guide
References: Design Patterns (GoF, 1994) · Analysis Patterns (Fowler, 1996) · Patterns of Enterprise Application Architecture
(Fowler, 2002) · Clean Architecture (Martin, 2017)
Design Patterns Reference Guide Page 16