Module E1 of 3 · Exam and certification

Course revision guide

45 min 3 stages distilled 4 figures

The whole course in one place, arranged for revision. Each stage below gives you its figure, the distinctions worth holding in your head, and the fastest routes back into the full material. Skim the figures first, then test yourself against the distinctions: anything you cannot explain from memory points at the stage to revisit.

Architecture as a decision-evidence-governance loop

Six stages run from Context to Governance, and the dashed arrow carries evidence back to Context, so a decision the running system contradicts is reopened rather than left standing as the record.

The spine repeats: every operating signal can promote, supersede, or revisit a decision. Source: Bass, Clements, Kazman, Software Architecture in Practice, 4th ed., 2021.

Architecture is a continuous decision-evidence-governance loop Two coordinated views. The top view is a six-row vertical stack of spine stages Context, Boundaries, Trade-offs, Decision, Evidence, Governance with a citation per row. The Decision row is emphasised in brand red because the ADR is the primary artefact. The bottom view is the cyclical flow: six cards joined by labelled arrows with a dashed feedback arrow looping from Governance back to Context labelled 'evidence reopens the loop'. SIX STAGES · ARCHITECTURE DECISION SPINE 01 Context Stakeholders, drivers, constraints, options Bass et al. 2021 §1.1 02 Boundaries Modules, services, interfaces, ownership Parnas 1972 03 Trade-offs Quality attributes weighed and measured ISO/IEC 25010:2023 04 Decision Recorded with options, context, consequences Nygard 2011 05 Evidence Tests, metrics, traces test it in production Google SRE 2016 06 Governance Reviewed, accepted, superseded, or retired Open Group TOGAF 10 THE LOOP · EVIDENCE REOPENS EACH STAGE 01Context 02Boundaries 03Trade-offs 04Decision 05Evidence 06Governance frames expose select tested by informs evidence reopens the loop

Stage 1: Which decisions are architectural, and what evidence makes a quality claim real

Architectural decisions are hard to reverse and wide in effect

The 2 by 2 runs reversibility across and blast radius down, so the cost of a choice is set by the cell it lands in: the system-wide, one-way cell holds the persistence store and the tenancy model, reversed only by a migration.

Most pull-request choices live in the top-left cell; architectural decisions live in the bottom-right. Source: Bezos 1997; Fairbanks, Just Enough Software Architecture, 2010; Bass et al. 2021.

Architectural decisions are hard to reverse and wide in effect A 2 by 2 matrix. Columns are reversibility, two-way on the left and one-way on the right. Rows are blast radius, local on top and system-wide on the bottom. The four cells name a representative decision archetype with one example. The bottom-right cell is emphasised: it is the ADR zone where architectural decisions belong. BLAST RADIUS Local System-wide TWO-WAY · EASY TO REVERSE ONE-WAY · HARD TO REVERSE PULL REQUESTLocal, two-wayTweak a parameter,revert by editing the commit. BUILD CHOICELocal, one-wayPick a framework inside a service,reverse with a rewrite. GOVERNED ROLL-OUTSystem-wide, two-wayFeature flag a behaviour change,roll back by flipping the flag. ADR ZONESystem-wide, one-wayPersistence store, tenancy model,reversed only by a migration. The bottom-right cell is where architecture lives. Source: Fairbanks 2010, Bass et al. 2021.

Hold these distinctions

  • Architecture versus design versus implementation: architecture fixes the major parts, how they communicate and what constrains their evolution; design fixes how one component is organised internally; implementation fixes how a specific piece of logic works. Only the first is expensive to reverse
  • Functional requirement versus quality attribute: the first says what the system does and the second says how well it does it. A system can satisfy every functional requirement and still fail catastrophically, which is what the Knight Capital incident of 1 August 2012 demonstrated
  • Cohesion versus coupling: cohesion measures whether the things inside a component belong together, coupling measures how dependent components are on each other. Well-placed boundaries improve both simultaneously, and a boundary that improves only one is usually in the wrong place
  • Content coupling versus data coupling: content coupling reaches into another component's internal state and leaves no contract to protect either side; data coupling passes well-defined parameters through a declared interface and is the form to aim for
  • Strict versus relaxed layering: strict layering permits a call only to the layer immediately below and suits certified or safety-critical domain logic; relaxed layering permits a call to any layer below and suits thin, data-entry-heavy applications. Both keep the downward dependency rule
  • Authentication versus authorisation: authentication establishes who is calling, authorisation decides what that caller may do. Checking the first and inferring the second is how elevation of privilege happens on a fully encrypted connection
  • Continuous delivery versus continuous deployment: continuous delivery means every passing build could be deployed and a human decides when; continuous deployment means every passing build goes to production automatically. A change approval gate is compatible with the first and not the second
  • Deployment versus release: deployment puts code on the production estate, release exposes it to users. Feature flags separate the two, which is what makes a kill switch faster than a rollback
  • C4 container versus component: a container is something separately deployable and runnable, such as an API or a database; a component is a logical building block inside one container. Technology names belong at container level and never at system context level
  • A protocol being stateless versus an application being stateful: HTTP is stateless because each request can be understood in isolation, while sessions and tokens add application state on top. Both statements can be true of the same system at once
  • Proposed, accepted, deprecated and superseded: a record's status is the lifecycle, and superseding is a new record with a forward link rather than an edit to the old one
Full stage summaryScenario practice

Stage 2: Where a service boundary goes, and what distribution costs once it is drawn

Monolith, modular monolith, microservices: one trade-off space

The three styles are read down the same three measures: team autonomy, operational cost and change cost. Microservices buy high autonomy with expensive operations, which leaves the modular monolith, medium autonomy at cheap operations, as the middle option most teams skip past.

Pick the cell whose operational and change costs you can absorb today; do not promote yourself up a ladder. Source: Fowler 2015 Monolith First; Newman 2021 Building Microservices 2nd ed.; Richards and Ford 2020.

Monolith, modular monolith, microservices: one trade-off space Three side-by-side cards Monolith, Modular Monolith emphasised, Microservices. Each card carries the deployment shape eyebrow, the style name, and three measurable trade-offs: team autonomy, operational cost, change cost. A canonical citation sits at the bottom of each card. The Modular Monolith card is emphasised in brand red because most teams under-shoot it. DEPLOYMENT STYLE · A TRADE-OFF, NOT A LADDER ONE DEPLOY · ONE PROCESS Monolith TEAM AUTONOMY Low OPERATIONAL COST Cheap CHANGE COST Low if codebase stays small Fowler 2015 ONE DEPLOY · MANY MODULES Modular Monolith TEAM AUTONOMY Medium OPERATIONAL COST Cheap CHANGE COST Low if module boundaries stay clean Richards and Ford 2020 MANY DEPLOYS · MANY PROCESSES Microservices TEAM AUTONOMY High OPERATIONAL COST Expensive CHANGE COST Low only with a strong platform Newman 2021

Hold these distinctions

  • Monolith versus modular monolith versus microservices: one deployment over one database, one deployment with enforced internal interfaces, and many independently deployable services each owning its own data; only the third pays for distribution, and only the third buys independent release
  • Microservice versus distributed monolith: the label is earned by single business capability, own process and own data store held at once, and a set of services sharing a database is a monolith that has added network calls to its failure modes
  • Event versus command versus integration event: an event is a past-tense fact whose producer does not know its consumers, a command is an instruction to a named receiver that fails if the receiver refuses, and an integration event is a domain fact translated for a different bounded context
  • Log-based versus queue-based brokers: Kafka retains a partitioned log that many consumer groups read independently and can replay, while RabbitMQ deletes a message once acknowledged and routes each one to a single worker, which is why one suits shared streams and the other suits work distribution
  • At-least-once versus exactly-once: at-least-once is the default and makes idempotent consumers mandatory, while exactly-once requires producer idempotence and transactional consumers and buys its guarantee with latency and operational complexity
  • Backward versus forward compatibility: backward means a new schema can read old data, which adding a field with a default gives you; forward means an old schema can read new data, which holds when consumers ignore unknown fields; renaming, retyping or removing a required field is neither
  • CQRS versus event sourcing: CQRS separates the write model from the read model, event sourcing makes an append-only event log the source of truth, and either can be adopted without the other
  • Aggregate versus entity or table: an aggregate is drawn around the invariants that must hold in one transaction and may span several tables, while normalisation is drawn around storage; a large aggregate is a contention hotspot rather than a richer model
  • Bounded context versus microservice: the first is a boundary of meaning and ownership drawn from the domain, the second is a unit of deployment, and the mapping between them is a decision rather than an identity
  • Circuit breaker versus bulkhead versus retry: the breaker turns a slow failure into a fast one, the bulkhead stops one dependency's exhaustion reaching the other pools, and the retry only addresses a failure that will clear on its own within milliseconds
  • Read replica versus shard: a replica adds read capacity and costs replication lag, so a user's own just-written data must still be read from the primary, while a shard adds write capacity and costs cross-shard queries, rebalancing and distributed transactions
  • Vertical versus horizontal scaling: vertical needs no application change and ends at a hardware ceiling with one point of failure, while horizontal has no ceiling but requires statelessness, since local session state stops the load balancer routing the next request anywhere else
Full stage summaryScenario practice

Stage 3: Running the system: ports, releases, evidence and the governance around them

Hexagonal architecture: domain at the centre, ports out, adapters outside

Every arrow runs inward, adapters into ports and ports into the domain, and none runs outward, so the Postgres adapter can be replaced without editing a domain that knows only its ports.

Adapters depend on ports; ports depend on the domain; the domain depends on nothing outside itself. Source: Cockburn 2005 Hexagonal Architecture; Martin 2017 Clean Architecture; Vernon 2013.

Hexagonal architecture: domain at the centre, ports out, adapters outside Three concentric rings of cards. The Domain card sits at the centre emphasised in brand red with the note 'no outward references, knows only its ports'. Four port cards arrange around it (HTTP, CLI, Repository, External API) with eyebrows DRIVING or DRIVEN. Four adapter cards sit on the outside (Express handler, yargs CLI, Postgres adapter, REST client). Inward arrows flow from adapters to ports and from ports to the domain; nothing flows outward. OUTSIDEExpress handler OUTSIDEyargs CLI OUTSIDEPostgres adapter OUTSIDEREST client DRIVINGHTTP port DRIVINGCLI port DRIVENRepository port DRIVENExternal API port INSIDEDomainNo outward references.Knows only its ports.

Hold these distinctions

  • Driving port versus driven port: a driving port is the interface the application exposes to callers, and an HTTP controller, a command line tool and a test case are all adapters on that side; a driven port is the interface the application defines for the infrastructure it needs, and the database or broker adapter implements it
  • Hexagonal and clean architecture versus layered architecture: the difference is ownership of the interface, not the shape of the diagram, because the application declares the driven port in its own package and the infrastructure implements an interface it does not own
  • Serverless versus edge: central functions run for up to fifteen minutes on a general runtime with cold start exposure, while edge functions run in a lightweight isolate at a point of presence with a very small CPU budget and no direct database connection, so one is for work and the other is for decisions
  • Indicator versus objective versus agreement: the indicator is what you measure, the objective is the internal target over a window with its implied error budget, and the agreement is the contractual commitment with a penalty, which should always be looser than the objective
  • Metrics versus traces versus logs: metrics alert you that something is wrong, traces localise where in the request path the time or the failure sits, and logs tell you what happened at that point, which is why per-service metrics can look healthy while an end-to-end path is broken
  • Blue-green versus canary versus rolling: blue-green reverses by redirecting traffic to an environment still running, canary limits exposure and promotes on measured indicators, and rolling replaces instances in batches and therefore requires backwards-compatible changes throughout the window
  • Deployment versus release: deployment puts code in production, release exposes behaviour to users, and a feature flag separates them so that reversal after full rollout is a configuration change rather than a pipeline run
  • Choreography versus orchestration: choreography has services react to events with no coordinator, which suits short chains, while orchestration puts the sequence and the compensation logic in one place, which is easier to observe and debug at the cost of a coupling point
  • Saga versus two-phase commit: two-phase commit buys atomicity with distributed locks that fail badly when a participant dies mid-protocol, while a saga chains local transactions with compensations and gives eventual consistency in which intermediate states are visible
  • At-least-once delivery versus idempotent processing: at-least-once is a property of the transport, which will redeliver after a crash, and idempotency is a property the receiver has to implement, usually with a stored result keyed by a caller-supplied identifier
  • Centralised versus federated versus decentralised governance: centralised approval buys consistency and creates a queue, decentralisation buys speed and produces fragmentation, and federation sets standards and constraints centrally while leaving decisions inside the guardrails to teams
  • Sensitivity point versus trade-off point versus risk: a sensitivity point is where one decision moves a quality attribute sharply, a trade-off point is where improving one attribute degrades another, and a risk is a decision that may not survive uncertainty in the requirements
  • Testing versus chaos engineering: a test verifies that code does what it was written to do, while a chaos experiment verifies that the system behaves as predicted when the infrastructure around it fails, which is why it needs a steady state, a hypothesis and an abort condition rather than an assertion
Full stage summaryScenario practice

Exam technique for the two papers

The Foundation paper is 40 single-answer questions in 60 minutes, closed book, and it tests precise recall. Revise the definitions that separate near neighbours: cohesion from coupling, content coupling from data coupling, authentication from authorisation, continuous delivery from continuous deployment, deployment from release, a container from a . In the sitting, read the stem twice and decide what is actually being asked before looking at the options, because many questions turn on one qualifying word.

The options are written so that measuring them does not help. The correct answer is as often the short one as the long one, and no option is there to be eliminated for being obviously silly, so eliminate on meaning rather than on shape. A precise claim beats a sweeping one, and an option that would be true of a different pattern is the commonest way to be wrong.

The Practitioner paper is 8 workplace scenarios in 90 minutes, open book, scored five, three, one and zero. Rank the options rather than hunting a single right answer. Across this course the five-point answer almost always establishes what the decision has to satisfy before acting on it: it names the at stake and the evidence that would settle it, rather than reaching for the pattern that is usually right. The three-point answer is normally real work aimed slightly wrong, most often sequenced too early or scoped too wide. Use the reference panel to confirm a distinction, not to learn the topic inside 90 minutes.

The primary sources behind the course

Version-sensitive claims across the course anchor to primary, dated sources, and every stage summary cites the ones its teaching rests on. They are collected here so revision starts from the authority rather than from a summary of it.

When the distinctions hold from memory and the figures feel obvious, you are ready to drill the papers and then sit the mocks.

Start the exam practiceGo straight to the mocks