Module 2: Architecture Patterns & Modular Monoliths
Primary text: Fundamentals of Software Architecture (Richards & Ford), Part II
Selective support: Clean Architecture (Martin) for boundaries and components, Just Enough Software Architecture (Fairbanks) for framing, Learning Domain-Driven Design (Khononov) only for mapping contexts to services, Software Architecture: The Hard Parts and canonical web references from Martin Fowler, Sam Newman, and Chris Richardson for cross-checks
This guide is the primary teacher. You do not need to read the source books front-to-back. You do need to leave this module able to name, sketch, and defend every major architecture style, and to tell the difference between "we chose a style" and "we slid into one by accident."
Scope of This Module
Architecture styles are the recurring shapes systems take. They are not neutral menu items: each one encodes a set of bets about scaling, team size, deploy cadence, failure modes, and how much distributed-systems pain you are willing to pay. Picking one is a commitment; outgrowing one is expensive.
What it covers in depth:
- layered architecture, the default you inherit, and why its "layers of isolation" concept matters
- pipeline (pipe-and-filter) architecture for data transformation and ETL
- modular monoliths: the single-deployment system with internal module boundaries that many teams should actually prefer
- component boundaries, cohesion, coupling, and the afferent/efferent couple metrics
- enforcing module boundaries in code with tools like ArchUnit and Packwerk, and with discipline
- service-based architecture: coarse-grained services that share a database and keep operations simple
- event-driven architecture: broker and mediator topologies, async capabilities, and their cost
- space-based architecture as the high-scale, in-memory-data-grid pattern
- microservices: bounded-context sized, independently deployed services, and the cost you pay for them
- the microservices tax: network, debugging, deploys, data, and consistency costs explicitly enumerated
- selecting a style by architectural characteristics from M01
- the fallacies of distributed computing applied to style choice
- hybrid architectures and evolution paths (monolith-first, extract-a-service, rewrite-v2)
What it deliberately does not cover:
- orchestration-driven SOA beyond a historical sidebar (mostly legacy, M03 context)
- microkernel/plugin architecture beyond a named reference (rare in modern web systems)
- DDD patterns and bounded-context discovery (owned by M03)
- API-contract details for inter-service communication (owned by M04)
- ADR writing and review process (owned by M05)
- production concerns of the microservices tax beyond architectural cost (owned by S08 and S09)
Before You Start
Answer closed-book:
- Name three architectural characteristics from M01 that would push a team away from a modular monolith and toward microservices.
- In a layered architecture, what is the "architecture sinkhole anti-pattern"? Why is it dangerous?
- What is the difference between a mediator topology and a broker topology in event-driven systems? Which one adds a single point of failure and which one loses global visibility?
- A team says "we will split our app into microservices so we can deploy faster." What three questions do you ask before you agree?
- Name four fallacies of distributed computing and give one concrete production failure each one predicts.
Diagnostic Interpretation
4-5 solid answers - Ready for the full path.
2-3 solid answers - Continue, but expect extra time in Clusters 3 and 4.
0-1 solid answers - Revisit M01: Architecture Fundamentals & Quality Attributes. You cannot pick a style without the characteristics to pick by.
What This Module Is For
Every system has an architecture. The only question is whether anyone chose it.
Throughout the program and in real work, you will repeatedly be asked:
- what is the default architecture for this new product, and why not microservices?
- our monolith is painful; should we split it?
- which style does a reporting pipeline deserve? A real-time feed? A checkout flow?
- when our CTO says "we need to go event-driven," what exactly are we agreeing to?
- how will we recognize that we have outgrown the style we are on?
This module builds the style-selection and modularity reasoning needed for:
- bounded-context and service boundary design in M03
- API integration style decisions in M04
- ADRs and review packets in M05 and the semester project
- the distributed-systems work in S08
- the deployment and operations work in S09
You are learning to name the bet each style is making so you stop paying the cost of a style you never chose.
Concept Map
How To Use This Module
Work clusters in order. Cluster 4 (microservices) only makes sense after Clusters 2 and 3, because microservices is best understood as "modular monolith plus network plus independent deploy" and "an event-driven or service-based system with much smaller services."
Cluster 1: The Layered and Pipeline Patterns
| Order | Concept | Type | Focus |
|---|---|---|---|
| 1 | Layered Architecture: The Default, Its Pros and Sinkholes | PRIMARY | Topology, layers of isolation, sinkhole anti-pattern, when it is the right answer |
| 2 | Pipeline Architecture: Pipe-and-Filter for Data Transforms | PRIMARY | Filters, pipes, composability, ETL and batch workflows |
| 3 | When the Layered Default Is Wrong | PRIMARY | Failure modes of layered, signals to change style |
Cluster mastery check: Can you draw a clean layered diagram, name the sinkhole anti-pattern, and give two concrete scenarios where pipeline beats layered?
Cluster 2: Modular Monoliths and Component-Based Thinking
| Order | Concept | Type | Focus |
|---|---|---|---|
| 4 | Modular Monolith: The Right Default for Most Systems | PRIMARY | Single deployment, multiple internal modules, benefits, cost |
| 5 | Component Boundaries: Cohesion, Coupling, Afferent/Efferent | PRIMARY | Cohesion types, coupling types, Ca/Ce, instability, main sequence |
| 6 | Enforcing Module Boundaries in Code | PRIMARY | ArchUnit, Packwerk, fitness functions, PR review, package hygiene |
Cluster mastery check: Given a legacy folder structure, can you name the modules, compute coupling by inspection, and write one ArchUnit or Packwerk rule that would catch the next violation?
Cluster 3: Service-Based and Event-Driven Styles
| Order | Concept | Type | Focus |
|---|---|---|---|
| 7 | Service-Based Architecture: Coarse-Grained Services with a Shared DB | PRIMARY | 4-12 services, shared schema, operational simplicity |
| 8 | Event-Driven Architecture: Mediator vs Broker Topologies | PRIMARY | Broker choreography, mediator orchestration, async tradeoffs |
| 9 | Space-Based Architecture: The High-Scale Pattern | SUPPORTING | In-memory data grid, processing units, data pumps, when to reach for it |
Cluster mastery check: Given an e-commerce checkout vs a real-time bidding platform vs a weekly reporting job, can you pick between service-based, event-driven, and space-based and defend the choice?
Cluster 4: Microservices
| Order | Concept | Type | Focus |
|---|---|---|---|
| 10 | Microservices: Bounded-Context Sized, Independently Deployed | PRIMARY | Definition, bounded context sizing, independent deployability, data isolation |
| 11 | The Microservices Tax: Operational and Cognitive Cost | PRIMARY | Network, debugging, deploy, data, consistency, people tax |
| 12 | When Microservices Are Right -- and When They Absolutely Are Not | PRIMARY | Signals for and against, team topology, monolith-first default |
Cluster mastery check: Can you state, without looking, five concrete costs microservices impose, and describe one system shape where they are a terrible choice even though they are "modern"?
Cluster 5: Choosing a Style
| Order | Concept | Type | Focus |
|---|---|---|---|
| 13 | Style Selection by Architectural Characteristics | PRIMARY | Characteristics-driven selection, ratings tables, tradeoff matrices |
| 14 | Distributed Architecture Fallacies Applied to Style Choice | SUPPORTING | The 8 fallacies mapped to failure modes |
| 15 | Hybrid and Evolving Architectures: Starting Modular, Extracting Services | PRIMARY | Evolution paths, strangler fig, hybrids that actually work |
Cluster mastery check: Given a requirements brief with measurable quality-attribute scenarios, can you produce a short decision record selecting a style, naming the alternatives, and listing the characteristics you optimized for?
Then work these practice pages:
| Order | Practice path | Focus |
|---|---|---|
| 1 | Style Selection Lab | Given characteristics, pick and justify a style |
| 2 | Modular Monolith Boundaries Workshop | Sketch module graph, write boundary rules, identify violations |
| 3 | Microservices Decomposition Clinic | Decompose a monolith, price the tax, decide what not to split |
| 4 | Architecture Pattern Katas | Timed drills: style selection, topology diagram, critique, module graph |
Use Module Quiz after the concept and practice path. Use Reference and Selective Reading and Learning Resources for targeted reinforcement.
Learning Objectives
By the end of this module you should be able to:
- Name, sketch, and compare all seven mainstream architecture styles (layered, pipeline, modular monolith, service-based, event-driven, space-based, microservices).
- Identify the layered sinkhole anti-pattern and the cases where pipeline wins over layered.
- Explain what makes a monolith modular, and list the three main ways internal modules become coupled over time.
- Compute (by inspection) afferent and efferent coupling for a set of packages and name the unstable ones.
- Write boundary-enforcement rules that a CI job could actually run (ArchUnit style, Packwerk style, or language-agnostic fitness functions).
- Distinguish service-based, event-driven, and microservices architectures by granularity, data isolation, and communication style.
- Enumerate at least five concrete taxes microservices impose (network, debugging, deploys, data, consistency, people) with a production example for each.
- Apply the eight fallacies of distributed computing to predict failure modes of a style choice.
- Pick an architecture style for a given set of quality-attribute scenarios and defend the pick against at least two alternatives in writing.
- Describe a realistic evolution path from monolith through modular monolith to selective service extraction, and name what would trigger each step.
Outputs
- a one-page style catalog with ASCII or mermaid topology, characteristics ratings, and "use when / avoid when" for all seven styles
- a component-boundary worksheet for one real or sample codebase listing at least 6 modules, their Ca/Ce, and one instability concern each
- at least 3 written fitness-function rules (ArchUnit-like, Packwerk-like, or pseudo-code) that enforce module boundaries
- a microservices-tax ledger: for one proposed microservices split, name the cost in each of network, debug, deploy, data, consistency, and people
- a style-selection decision log: for at least 4 scenarios (checkout flow, ETL pipeline, real-time bidding, internal CRUD), a chosen style with 3 tradeoffs stated
- one short "how we would evolve" memo taking a monolith through modular monolith to selective service extraction, naming the trigger for each step
- a mistake journal naming at least 8 recurring style-choice errors (
microservices-as-default,layered-with-sinkhole,shared-database-microservices,broker-topology-with-no-observability, etc.)
Completion Standard
You have completed Module 2 when all of these are true:
- you can sketch the topology of all seven styles from memory in under 10 minutes
- you can state, in one sentence each, the primary failure mode of every style
- you can apply the architectural characteristics from M01 to produce a defensible style choice without consulting a rating table
- you can name at least five concrete microservices costs without hedging
- you can write one boundary-enforcement rule per language you work in
- you can describe one real system you have seen whose style was never chosen, only drifted into, and name what it was drifting toward
If you can name the styles but cannot tell when you are in the wrong one, the module is not complete.
Reading Policy
- Concept pages are the main path.
- Local book chunks from Fundamentals of Software Architecture Part II are the primary selective reinforcement.
- External URLs (martinfowler.com, samnewman.io, microservices.io, Microsoft architecture center, ArchUnit docs, Packwerk README) are permitted and cited in
resources.md. Read only if stuckmeans try the concept page, self-check, and drill first.- Written topology sketches are required deliverables, not optional enrichment.
Suggested Weekly Flow
| Day | Work |
|---|---|
| 1 | Concepts 1-3, sketch layered and pipeline topologies for one system each |
| 2 | Concepts 4-6, compute coupling for one real package graph and write one boundary rule |
| 3 | Concepts 7-9, diagram mediator vs broker for one workflow |
| 4 | Concepts 10-12, write the microservices-tax ledger for one candidate split |
| 5 | Concepts 13-15, produce one style-selection decision record from M01 scenarios |
| 6 | Practice pages 1-2 |
| 7 | Practice pages 3-4, quiz, mistake-log cleanup |
Reference
If you need exact links into the local chunked books, use Reference and Selective Reading.
Rich Learning Pages
Worked Examples | Guided Labs | Case Studies | Mistake Clinic | Reading Guide | Capstone Thread