Free to read ยท Three levels
Software Architecture: Boundaries, Decisions, and Evidence
Develop architectural judgment through measurable scenarios, modular ownership, interface contracts, distributed failure, operational evidence, and staged evolution.
Start learningIn this course
Eighteen developed lessons follow a fictional workshop-reservation system from its user promise to architecture review. Each lesson connects a particular design decision with its consequences, worked artifacts, realistic mistakes, and exercises with complete solutions. The course compares alternatives in context instead of prescribing one deployment style for every team.
All identities, workloads, durations, targets, states, records, and outcomes are synthetic. Examples are local models or editorial artifacts and never access accounts, databases, providers, brokers, or application services. Proposed tests remain proposals unless explicitly identified as executed local programs.
What you will learn
- Describe scope and quality scenarios with observable responses and explicit uncertainty.
- Design cohesive modules, stable contracts, and authoritative data ownership.
- Reason about asynchronous completion, crash windows, duplicate effects, and bounded resilience.
- Connect authorization, telemetry, caching, and capacity reasoning to the user promise.
- Plan compatible migration and review decisions through evidence, risk, and technical debt.
Your learning path
Three levels
Foundations: promises, structure, and ownership
Define consequential decisions, measurable quality, useful views, modular dependencies, contracts, and invariants.
- Architecture begins with consequential decisions
- Make quality goals measurable
- Use architecture views to answer different questions
- Design modules around change and dependency rules
- Specify contracts that survive independent change
- Protect invariants at the data owner
Interactions: distribution, failure, and operation
Compare deployment boundaries and design asynchronous work, consistency, resilience, authorization, and telemetry.
- Choose deployment boundaries from real independence needs
- Design asynchronous work with explicit completion and pressure
- Handle cross-boundary consistency without imaginary atomicity
- Bound failure with deadlines, retries, and isolation
- Design trust and authorization at every boundary
- Design observability around questions and ownership
Evolution: capacity, migration, validation, and review
Develop evidence-driven performance and caching decisions, compatible migration, meaningful checks, and maintainable architecture records.
- Reason about performance before changing topology
- Make caching a freshness and failure decision
- Migrate architecture through compatible stages
- Validate architectural claims with focused evidence
- Maintain decisions, risks, and technical debt honestly
- Review a complete reservation architecture proposal
Who this is for
- Developers learning to explain consequential design choices and maintain system boundaries.
- Technical leads and reviewers who need traceable assumptions, tradeoffs, and verification plans.
Before you start
- Basic programming, HTTP, database, and testing concepts; examples explain their architectural role.
- No cloud account, service credentials, deployment platform, or administrator access is required.