Foundations · Module 2
Architecture and design
Document and communicate architectural decisions using C4 models, Architecture Decision Records, API contracts, and security by design principles.
Previously
Discovery and requirements
Learn to identify what you're building and what could go wrong.
This module
Architecture and design
Document and communicate architectural decisions using C4 models, Architecture Decision Records, API contracts, and security by design principles.
Next
Implementation and build
Write secure, maintainable code with proper input validation, output encoding, session management, error handling, and supply chain security.
Progress
Mark this module complete when you can explain it without rereading every paragraph.
Why this matters
This module turns decisions into artefacts you can defend and share.
What you will be able to do
- 1 Explain architecture and design in your own words and apply it to a realistic scenario.
- 2 Architecture design is choosing boundaries, responsibilities, and the flows between them.
- 3 Check the assumption "Boundaries are explicit" and explain what changes if it is false.
- 4 Check the assumption "Decisions are recorded" and explain what changes if it is false.
Before you begin
- No previous technical background required
- Read the section explanation before using tools
Common ways people get this wrong
- Diagram-first design. If you draw before you understand, diagrams become fiction.
- Unowned interfaces. Interfaces without owners drift and break consumers.
Document and communicate architectural decisions using C4 models, Architecture Decision Records, API contracts, and security by design principles.
This module turns decisions into artefacts you can defend and share. Good architecture is visible in the reasoning, not only the diagram.
Mental model
Design as boundaries
Architecture design is choosing boundaries, responsibilities, and the flows between them.
-
1
Context
-
2
Containers
-
3
Interfaces
-
4
Flows
Assumptions to keep in mind
- Boundaries are explicit. If boundaries are not explicit, coupling grows in the dark.
- Decisions are recorded. A short ADR prevents future confusion and accidental reversals.
Failure modes to notice
- Diagram-first design. If you draw before you understand, diagrams become fiction.
- Unowned interfaces. Interfaces without owners drift and break consumers.
Check yourself
Quick check. Architecture and design
0 of 5 opened
What is an ADR used for
To record a decision, the context, options considered, and why the chosen path was selected, so the reasoning survives change.
What does a C4 context diagram show
Users, the system, external systems, and key relationships, including boundaries and assumptions.
What is a trust boundary
A place where assumptions change, such as between browser and server, or between your service and a vendor.
Scenario. An API changes a field name. What does versioning protect
Downstream consumers. It prevents silent breakage and gives teams a controlled migration path.
Why aim for the smallest useful diagram
Because clarity beats decoration. A smaller diagram is easier to keep accurate and easier for a team to use under pressure.
Artefact and reflection
Artefact
A short module note with one key definition and one practical example
Reflection
Where in your work would explain architecture and design in your own words and apply it to a realistic scenario. change a decision, and what evidence would make you trust that change?
Optional practice
C4 models, ADRs, API contracts, and security by design