LearningTree
Software Architecture
Patterns
A structured reference covering foundational architecture patterns: Layers, Pipes & Filters, Microservices, and Dependency Injection.
01
Chapter One
Introduction to Patterns
What Patterns Reuse
Patterns allow us to reuse "thinking" — applying proven solutions to problems across different domains and levels of abstraction. They are discovered, not invented, and appear in software architecture, design, physical architecture, and many other fields.
Libraries
Allow us to reuse code — pre-built implementations that can be called from your own code.
Frameworks
Allow us to reuse structure — predefined application skeletons and control flows you fill in.
Patterns
Allow us to reuse thinking — applying solutions to problems across different domains and abstraction levels.
What Patterns Do
- Describe reusable (abstract or concrete) solutions for common problems
- Provide a recognizable structure and terminology for those solutions
Patterns Are Discovered, Not Invented
The universe is full of them. Patterns have been discovered in many fields:
- Software architecture
- Software design
- Analysis
- Physical (buildings) architecture
- Gardening, teaching, …
Designing With Patterns
Patterns offer approaches for:
- Decomposition of a system
- Distribution of responsibilities within a system
Patterns complement each other:
- Refinement and combination
Pattern Classification
Architectural — Buschmann [Bus+1996]
- Adaptable Systems
- Interactive Systems
- Mud-to-Structure
- Distributed Systems
Design Patterns — GoF [Gam+1994]
- Creational
- Structural
- Behavioral
Others: enterprise integration, enterprise architecture, microservices, concurrency, …
Must-Know Patterns for CPSA-F
ISAQB CPSA-F Required (R1, R2) — Most Fundamental
Layers Pattern Pipes and Filters Microservices Dependency Injection
Note: There are many more patterns (Singleton, Observer, CQRS, Event Sourcing, etc.) — you need to be aware of as many as possible, but the four above are considered the most fundamental for the exam.
Patterns in Practice — Common Problems → Common Solutions
💻
Operating System
🔄
IoT Vacuum Cleaner
🛒
Large Scale Online Store
🏦
Banking Application
↓
Common Design & Architecture Problems
↓
Common Solutions — Patterns
📋 Chapter 1 — Summary
- Libraries reuse code; Frameworks reuse structure; Patterns reuse thinking
- Patterns describe reusable (abstract or concrete) solutions for common problems
- Patterns are discovered, not invented — the universe is full of them
- Patterns offer approaches for decomposition and distribution of responsibilities
- Patterns complement each other through refinement and combination
- CPSA-F must-know patterns: Layers, Pipes & Filters, Microservices, Dependency Injection
02
Chapter Two
Layers Pattern
Layers Pattern — Overview
The Layers Pattern organizes components into stacked layers of services, where each layer encapsulates details, provides abstraction, and communicates with adjacent layers. Dependencies flow downward only — upper layers depend on lower layers, never the reverse.
📦 Each Layer
- Encapsulates details
- May provide abstraction
- Provides services to the layer above
🔗 Dependencies
- Can depend on layers below it
- Cannot depend on layers above it
📤 Usage
- Usage directed from upper to lower layer
⇅ Communication
- Communication can be directed in both ways
Layer Stack
Highest abstraction
Client
uses →
Layer N
⇅ communicate
Layer N-1
⇅ communicate
Layer 1
Lowest abstraction
OSI Model — Abstraction Layers Example
| # | Layer | Responsibility |
|---|---|---|
| 7 | Application | High-level APIs |
| 6 | Presentation | "Data translator", encryption, compression |
| 5 | Session | Managing communication sessions |
| 4 | Transport | Reliable transmission of data |
| 3 | Network | Addressing, routing and traffic control |
| 2 | Data Link | Reliable transmission of data frames |
| 1 | Physical | RX/TX physical medium |
Example: ISO Open Systems Interconnection (OSI) model
Multi-Layered / N-Layered Web Architecture
Presentation Layer
User interaction · HTTP Requests · Input validation · HTTP responses
⇅
Business Logic Layer
Business rules · Data validation · Access control · Computations
⇅
Persistence Layer
Database / File System · Object-storage mapping · Connections
Three-Tiered Architecture
Presentation Tier
Webpage
Mobile App
→
Application Tier
Web App Server
UI · Logic · Data
→
Data Tier
Files
Database
Note: Each tier can itself contain layered architecture internally (UI → Logic → Data sublayers within the Application Tier, API → Query Engine → Logic → Storage within the Database).
Example — Layers Within Tiers
Online Bookstore — Each Tier Contains Its Own Layers
👤 User (Browser / Mobile)
↓ HTTP
→
→
Tiers = physical separation (deployment) · Layers = logical separation (within each tier)
Closed vs Open Layer Architecture
Closed / Strict Layer Architecture
Presentation Layer Closed
↓ must pass through ↓
Business Logic Layer Closed
↓ must pass through ↓
Persistence Layer Closed
Each layer can only interact with the layer directly below. No skipping.
Open Layer Architecture
Presentation Layer Closed
↓ or skip ↘
Business Logic Layer Open
↓
Persistence Layer Closed
Higher layers may call any layer below. Open layers can be bypassed.
Layer Architecture Types — Trade-offs
Closed/Strict Layer
Advantages
- Modularity
- Simplifies debugging and testing
Disadvantages
- Potential inefficiency / performance overhead
Open Layer
Advantages
- Can bypass layers: higher efficiency / performance
Disadvantages
- Harder to understand/maintain
- Risk of bugs
Layers Pattern — Pros & Cons
✓ Pros
✗ Cons
- Layers are independent — distribution of tasks during development
- Layers are independent in production — installation and maintenance
- Implementations are interchangeable
- Unidirectional dependencies (no circular dependencies)
- The Layers pattern is easy to understand
- Layers are overhead when they only pass information to following layers
- Loose layering allows skipping layers (open) but increases dependency
- Some changes (e.g., adding a data field) may require changes to all layers
📋 Chapter 2 — Summary
- Each layer encapsulates details and provides services to the layer above
- Dependencies are unidirectional: upper layers depend on lower, never circular
- Closed/Strict: each layer may only interact with the layer directly below
- Open: higher layers may call any layer below, bypassing intermediate layers
- Example: OSI 7-layer model, Web architecture (Presentation → Business → Persistence)
- Pro: independent layers, easy to understand. Con: overhead, changes may ripple
03
Chapter Three
Pipes and Filters Pattern
Pattern Components
The Pipes and Filters pattern decomposes a processing task into a sequence of independent processing steps (Filters) connected by channels (Pipes). Each Filter is unaware of others, transforming or manipulating data independently, enabling simple composition of complex pipelines.
🔗
Pipes
- Transport data/messages between filters
- Can buffer data
- Connect one filter's output to another's input
Source
buffer
Filter
⚙️
Filters
- Processing unit, unaware of other filters
- Transform, aggregate, or manipulate data
- Connects to multiple input/output pipes
in →
⚙️ Filter
→ out
Pipes and Filters — Flow Diagram
Pipeline Architecture — Data flows left to right through independent filters
📥 Data
Source
Source
producer
pipe · buffer
⚙️ Filter
1 — Transform
unaware of others
pipe · buffer
⚙️ Filter
2 — Aggregate
unaware of others
pipe · buffer
⚙️ Filter
3 — Enrich
unaware of others
pipe · buffer
📤 Data
Sink
Sink
consumer
🔗 Pipe
Transports data · Can buffer · Connects output → input
⚙️ Filter
Independent · Unaware of others · Transform / Aggregate / Enrich
📤 Sink
Final consumer · Stores or forwards the processed result
Unix/Linux Pipe Example
cat input.txt | grep 'search_term' | sort | uniq -c
cat = source | = pipe (OS buffer) grep = filter 1 sort = filter 2 uniq -c = sink
Programs/Processes connected by OS-allocated buffers as pipes
Real-World Examples
🎬
Video Encoding Pipeline
each filter runs on its own thread · FIFO queue as pipe
🎥
Raw Video
Raw Video
FIFO
⚙️ Decompress
h.264 → raw frames
FIFO
⚙️ Resize
1080p → 720p
FIFO
⚙️ Color Correct
brightness/contrast
FIFO
⚙️ Watermark
overlay logo
FIFO
⚙️ Compress
encode h.265
FIFO
📁
Output File
Output File
📊
ETL Big Data Pipeline
feeds BI · dashboards · ML models
🗄️ DB
☁️ Lake
📡 API
stream
⚙️ Extract
read sources
normalise format
normalise format
pipe
⚙️ Transform
clean · enrich
aggregate · join
aggregate · join
pipe
⚙️ Load
write to sink
validate schema
validate schema
pipe
🏛️ Data Warehouse
📈 BI
📊 Dash
🤖 ML
🔄
API Data Ingestion Pipeline
each filter is independent — easy to add, remove, or reorder
Raw JSON from an API flows through 4 sequential filters before being stored. Each filter handles one concern only.
📨
Raw
data in
⚙️ Parse
filter
JSON → objects
decode bytes
detect encoding
decode bytes
detect encoding
⚙️ Validate
filter
schema check
required fields
type coercion
required fields
type coercion
⚙️ Transform
filter
map fields
normalise dates
currency convert
normalise dates
currency convert
⚙️ Enrich
filter
geo-lookup
add metadata
join ref data
add metadata
join ref data
🗄️
Store
data out
← pipes (buffers between each filter) →
💡 Reusability: any filter can be swapped, reordered, or removed independently — e.g. insert a
Deduplicate filter between Validate and Transform without touching the others.
Pipes and Filters — Pros & Cons
✓ Pros
✗ Cons
- Simple (linear) dependencies
- Flexible — filters can be composed in many ways
- Easily scalable
- Filters can be developed independently
- Difficult error tracking and handling
- Buffers might overflow
- Sharing global data might be difficult
📋 Chapter 3 — Summary
- Pipes transport data/messages between filters and can buffer data
- Filters are processing units, unaware of other filters
- Filters transform, aggregate, or manipulate data
- Filters connect to multiple input/output pipes
- Real examples: Unix pipes, GStreamer, ETL pipelines, video encoding
- Pro: flexible, scalable. Con: error tracking is hard, buffers may overflow
04
Chapter Four
Microservices Architecture
Monolithic Architecture — The Problem
Microservices architecture divides large systems into small, independently deployable units. Each microservice can be developed, deployed, scaled, and replaced independently, communicating over networks. It is ideal for large organizations with complex, big codebases.
As Codebase Grows, It Becomes Difficult To:
- Troubleshoot
- Add new features
- Build
- Test
- Load in IDE
Organizational Scalability Problems
- More engineers → more code merge conflicts
- Meetings become larger, longer, less productive
- Solution: consider migrating to Microservices
Microservices Architecture
Divide large systems into small, independently operable units.
Microservices can be individually
🛠️ Developed
🚀 Deployed
⚙️ Operated / Maintained
🔄 Changed / Replaced
📈 Scaled
🌐 Services communicate over networks
Online Shopping Service
Client
↓ API Gateway
Customer Account Service
Customer DB
Product Catalog Service
Product DB
Shopping Cart Service
Cart KVS
Order Dispatch Service
Order DB
Each service: independently deployed · own database · communicates over network
Benefits of Smaller Codebase per Service
✅
Easier
- Understand
- Develop
⚡
Faster
- Build
- Test
- Load in IDE
🎯
Simpler
- Troubleshoot
- Add new features
Microservices Benefits
① Polyglot Technology — each service picks its own language and data store independently.
🌐 API Gateway
↓↓↓↓
Order Service
Java · Order DB
Recommend
Python · Redis
User Profile
C# · SQL Server
Notification
Go · Kafka
Services only share an API contract — internal tech stack is fully independent
② Independent Scalability — scale only the service under load, not the entire system.
✗ Monolith
All features bundled
→ must scale everything
→ must scale everything
💸 wasteful
VS
✓ Microservices
User Service×1
🔥 Product Service×5
🔥 Order Service×4
Notification×1
✅ cost-efficient · fault-isolated
③ Higher Organisational Velocity — teams own, deploy, and operate their service independently (Inverse Conway Maneuver).
🚀 All teams deploy independently — no coordination meetings required
Key Design Principles
Single Responsibility Principle (SRP)
Each microservice owns one business capability. For example, in an online dating service: Image Service, User Profile Service, Matching Service, Billing Service — each routed through an API Gateway.
API Gateway
↙ ↓ ↓ ↘
Image
Profile
Matching
Billing
one service · one responsibility
Separate Database Per Microservice
- Each service owns its data store independently
- Some data duplication (breaking DRY) is expected
- Some performance overhead of getting data from another microservice (Cost of Information Hiding)
Order Service
↓
🗄️ Order DB
User Service
↓
🗄️ User DB
no shared data store · isolated ownership
Inverse Conway Law Maneuver: Organize teams around services (Subscription, Notification, Payments, Recommendations teams) so that team structure reflects the desired microservices architecture.
— Microservices Organizational Strategy
Microservices — Pros & Cons
✓ Pros
✗ Cons
- Improve changeability and flexibility
- Decouple technology decisions (polyglot)
- Multiple versions of a service can coexist
- Good scalability — scale individual services
- Fast development, short time-to-market
- Higher organizational velocity — independent teams
- All CONs of distributed computing: network latency, outages, bandwidth limitations
- More sophisticated error handling required
- More complex deployment/operations
- Dependency resolution at runtime may cause hard-to-find errors
Microservices are perfect for large organizations with complex, big codebases — but we don't get all the benefits for free. We need to follow design principles: Single Responsibility and database per microservice.
📋 Chapter 4 — Summary
- Divide large systems into small, independently operable units
- Each service can use a different technology stack (C#, Python, Java, Go)
- Services communicate over networks; separate database per service
- Benefits: smaller codebase, team autonomy, independent scaling
- Requires Single Responsibility Principle and database-per-service
- Con: distributed computing complexity, latency, error handling
05
Chapter Five
Dependency Injection Pattern
The Problem — Without Dependency Injection
Dependency Injection (DI) is the combination of Dependency Inversion Principle (DIP) and Inversion of Control (IoC). A dedicated Assembler component creates and injects concrete implementations into clients that depend on abstractions, decoupling high-level modules from low-level details.
Tight Coupling Problem
Without DI, PasswordManager directly depends on a concrete BcryptEncryptor:
Encryptor encryptor = new BcryptEncryptor();
PasswordManager pm = new PasswordManager(encryptor);
PasswordManager pm = new PasswordManager(encryptor);
Nightmare for big classes — creating large sets of lower-level classes manually. Hard to swap implementations.
With DI — Abstract Interface
PasswordManager depends on the Encryptor interface, not a concrete class:
private final Encryptor encryptor;
@Autowired
public PasswordManager(Encryptor enc) {
this.encryptor = enc;
}
@Autowired
public PasswordManager(Encryptor enc) {
this.encryptor = enc;
}
The framework injects the correct concrete implementation at runtime.
Dependency Injection — Architecture Diagram
The Assembler creates & injects the concrete implementation at runtime
Client
PasswordManager
PasswordManager
high-level module
── uses ──▶
«interface»
Encryptor
Encryptor
abstraction
↑
injects
△
implements
Assembler
DiAssembler
DiAssembler
creates at runtime
── creates ──▶
BcryptEncryptor
SHA2Encryptor
concrete implementations
DIP, IoC and DI — Relationships
DIP — Dependency Inversion Principle
- High-level modules should not depend on low-level modules
- Both should depend on abstractions
IoC — Inversion of Control
- Component registers itself with the framework, later called by the framework
- Third-party libraries define control flow
- Other applications: callbacks, scheduler, event loops, observer pattern
DI — Dependency Injection
- = Dependency Inversion Principle
- + Special application of IoC
- Creates and injects instances for abstractions a client depends on
DI = DIP + IoC
Dependency Injection = Dependency Inversion Principle + Inversion of Control
Java + Spring Example
Configuration-based injection: The DI framework reads a property (e.g.,
app.encryptor.type=bcrypt or sha2) and uses reflection to inject the appropriate implementation at runtime. The application code never needs to know which concrete class is used. application.properties
# Switch implementations without changing any Java code
app.encryptor.type=bcrypt
app.encryptor.type=bcrypt
Encryptor.java ← abstraction
public interface Encryptor {
String encrypt(String plainText);
}
String encrypt(String plainText);
}
BcryptEncryptor.java
@Component("bcrypt")
public class BcryptEncryptor
implements Encryptor {
@Override
public String encrypt(String p) {
return BCrypt.hashpw(
p, BCrypt.gensalt());
}
}
public class BcryptEncryptor
implements Encryptor {
@Override
public String encrypt(String p) {
return BCrypt.hashpw(
p, BCrypt.gensalt());
}
}
SHA2Encryptor.java
@Component("sha2")
public class SHA2Encryptor
implements Encryptor {
@Override
public String encrypt(String p) {
return DigestUtils
.sha256Hex(p);
}
}
public class SHA2Encryptor
implements Encryptor {
@Override
public String encrypt(String p) {
return DigestUtils
.sha256Hex(p);
}
}
PasswordManager.java ← client (never references a concrete class)
@Service
public class PasswordManager {
private final Encryptor encryptor; // depends on abstraction, not impl
@Autowired
public PasswordManager(
@Qualifier("${app.encryptor.type}") Encryptor encryptor) {
this.encryptor = encryptor; // Spring injects at runtime
}
public String hashPassword(String password) {
return encryptor.encrypt(password); // calls Encryptor interface
}
}
public class PasswordManager {
private final Encryptor encryptor; // depends on abstraction, not impl
@Autowired
public PasswordManager(
@Qualifier("${app.encryptor.type}") Encryptor encryptor) {
this.encryptor = encryptor; // Spring injects at runtime
}
public String hashPassword(String password) {
return encryptor.encrypt(password); // calls Encryptor interface
}
}
Change app.encryptor.type=sha2 in properties → SHA2Encryptor is injected. Zero code change.
Dependency Injection — Pros & Cons
✓ Pros
✗ Cons
- Supports the open-closed principle, loose coupling, and dependency inversion
- Manage dependencies "by configuration"
- Vastly improves extensibility
- Vastly improves flexibility and adaptability
- Vastly improves testability (mock components)
- Better readability of code
- Hard learning curve for developers
- Shifts complexity to DI frameworks
- Static analysis is difficult/impossible
- Things fail at run time (not compile time)
📋 Chapter 5 — Summary
- DIP: high-level modules should not depend on low-level modules — both depend on abstractions
- IoC: third-party libraries define control flow rather than application-specific components
- DI = DIP + IoC: assembler creates and injects implementations at runtime
- Two injection styles: setter injection and constructor injection
- Pro: loose coupling, extensibility, testability (mock components)
- Con: hard learning curve, runtime failures, shifts complexity to DI framework
Summary — All Architecture Patterns at a Glance
01 · Introduction to Patterns
What & Why
- Proven, reusable solutions to recurring design problems
- Provide shared vocabulary for architects & developers
- Patterns vs. Practices — know the difference
02 · Layers Pattern
Horizontal Separation
- Organize code into horizontal layers (presentation, business, data)
- Each layer depends only on the layer directly below
- Promotes SoC, testability & replaceability
03 · Pipes & Filters
Data Transformation Pipeline
- Filters = independent processing steps; Pipes = connectors
- Each filter reads, transforms, and writes data
- Easily add, remove or reorder processing steps
04 · Microservices
Independently Deployable Services
- Small, autonomous services organized around business capabilities
- Independent deployment, scaling & technology choices
- Trade-off: operational complexity & distributed data management
05 · Dependency Injection
DIP + IoC in Action
- DIP — both high & low-level depend on abstractions
- IoC — framework controls flow; DI injects implementations
- Setter & constructor injection; great testability