Skip to course content

Software Architecture revision

Practice and strategy revision

The full long-form practice & strategy notes for slower review and revision.

  • Revision
  • 22 min read
  • 4,465 words
Return to the module-first stage pageOpen the workspaceSave CPD evidence

Use this page when

You want the full longer reading path

Revision is the slower recap surface. Use it to reread, scan, or print the stage in one place after you have already worked through the module-first path.

How to use revision properly

Revision is not the default route through the course. It is the slower surface for recap, printing, annotation, or audit-friendly reading after the shorter module pages have already done the teaching work in smaller chunks.

Full stage reading

Advanced architecture is about running big systems across many teams. You design for change, failures, and the messy reality of long lived software.

Domains and bounded contexts

Domain driven design starts with language. A domain (The core problem space your software is meant to solve.) is not the same as a UI screen. A bounded context (A boundary where terms have one clear meaning.) keeps teams aligned.

Learning contract

Domains and bounded contexts

ubiquitous language (
Shared words that mean the same thing to developers, product, and domain experts.
)
When contexts blur, systems become expensive to change. Clear language and boundaries protect velocity.

Interactive diagram

Interactive diagram

Optional tool

Domain and bounded context mapper

Group features into contexts and spot overloaded boundaries.

Use the related workspace if you need the live interactive version.

Worked example. “Customer” means two different things and your system pays the price

One team uses “customer” to mean “bill payer”. Another uses it to mean “occupier”. Both are reasonable in isolation. The problem is when services silently mix them. You then get strange behaviour: wrong notifications, bad reporting, and angry users.

Common mistakes in bounded contexts

Verification. A quick boundary test

Reflection prompt

If you split your current system into contexts, where are the natural seams and why.

Knowledge check

Quick check. Domains and bounded contexts

Use this prompt as a self-check before you move on.

Concept recap

This recap has been simplified for the document surface. Use the workspace if you need the expandable concept tool.

Advanced patterns and distributed systems

Learning contract

Advanced patterns and distribution

CQRS (
Command Query Responsibility Segregation, where writes and reads use different models.
) event sourcing (
Store changes as a stream of events instead of overwriting records.
) saga (
A long business process split into steps with recovery paths if a step fails.
) idempotent (
Safe to run more than once without changing the final outcome.
)
These patterns help when you need scale and clarity, but they add complexity. Use them when the problem demands it.

CQRS operating path

Design for lag visibility, replay safety, and read correctness.

Interactive diagram

Optional tool

CQRS and events practice

Run a command and watch events and read models update.

Use the related workspace if you need the live interactive version.

Worked example. CQRS added for “scale”, but the real problem was a slow query

A team implements CQRS and events because reads are slow. After weeks of work, the system is more complex and the read model is still slow, because the real issue was one unindexed query and an N+1 access pattern.

Common mistakes with advanced patterns

Verification. When CQRS is justified

Reflection prompt

Which parts of your system would truly benefit from CQRS, and which would suffer.

Knowledge check

Quick check. Patterns and distribution

Use this prompt as a self-check before you move on.

Concept recap

This recap has been simplified for the document surface. Use the workspace if you need the expandable concept tool.

Resilience, performance and scale

Failures will happen. Resilience is about what you do when they do. circuit breaker (A safety switch that stops calls when a dependency is failing.) protects systems from cascades. backpressure (A way to slow or shed load so the system stays stable.) keeps things alive.

Learning contract

Resilience and performance under failure

Caching helps, but it creates new risks. Always decide where stale data is acceptable.

Resilience mesh

Protect service calls with layered controls and clear fallback logic.

Interactive diagram

Optional tool

Resilience and latency simulator

Adjust timeouts and retries to see the risk balance.

Use the related workspace if you need the live interactive version.

Worked example. Retries turned a small outage into a full incident

A dependency slows down. Callers timeout and retry with no jitter. Load multiplies, queues fill, and what started as “a bit slow” becomes total failure. This is why resilience is a system property, not a library checkbox.

Common mistakes in resilience

Verification. A resilience review in five questions

Reflection prompt

Where do timeouts or retries make things worse in your current system.

Knowledge check

Quick check. Resilience and scale

Use this prompt as a self-check before you move on.

Concept recap

This recap has been simplified for the document surface. Use the workspace if you need the expandable concept tool.

Architecture evolution and governance

Learning contract

Evolution and governance

fitness function (
An automated check that ensures architecture rules stay true over time.
) technical debt (
Work you postpone now that will cost more to fix later.
)
Architects guide change with small decisions, not massive documents. ADRs make intent visible. Fitness checks catch drift early.

ADR lifecycle

Keep architecture decisions short, testable, and reviewable.

Interactive diagram

Optional tool

Architecture decision workbench

Capture decisions, status, and risk tags.

Use the related workspace if you need the live interactive version.

Worked example. The same argument every quarter because nothing is written down

Teams re-litigate the same decisions: “monolith vs services”, “SQL vs NoSQL”, “build vs buy”. The debate burns time because context and trade-offs are not captured, so new people restart the argument from scratch.

Common mistakes in governance

Verification. A healthy ADR set

Reflection prompt

Which decisions in your system should be recorded as ADRs this quarter.

Knowledge check

Quick check. Evolution and governance

Use this prompt as a self-check before you move on.

CPD evidence (advanced, still practical)

Concept recap

This recap has been simplified for the document surface. Use the workspace if you need the expandable concept tool.