Solution Architecture: Modules
The program teaches how to go from business requirements to a justified solution architecture: making quality attributes measurable, choosing a suitable style and integration pattern, designing data and security, and weighing cloud and cost trade-offs. The result is a solution documented with C4 and ADRs that has been through a review.
01
Requirements, quality attributes and constraints
Turn a vague business wish into verifiable quality scenarios.
- Functional versus non-functional requirements
- Quality attribute scenario format
- Constraints: budget, team, regulation, legacy
- Trade-offs between attributes
- Surfacing ambiguity in requirements
Lab: From a given business description, produce eight quality scenarios and a prioritised constraint list.
02
Architecture styles and boundaries
Judge style choice in the context of team, requirements and growth stage.
- Monolith, modular monolith and microservice trade-offs
- Domain boundaries and bounded contexts
- Event-driven architecture and its cost
- Layered and hexagonal, and where each fits
- Evolutionary architecture and migration paths
Lab: Produce two style options for the same requirements, with a comparison table and a recommendation.
03
Integration patterns
Build reliable, change-tolerant links between systems.
- Choosing synchronous APIs versus asynchronous messaging
- Idempotency, retries and the outbox pattern
- API versioning and contract evolution
- Anti-corruption layer and external systems
- Saga and alternatives to distributed transactions
Lab: Design an integration flow with a payment provider and a warehouse system and tabulate the failure scenarios.
04
Data architecture
Balance data ownership, consistency and reporting needs.
- Per-service data and the shared database risk
- Choosing strong versus eventual consistency
- CQRS, read models and caching
- Data migration and zero-downtime approaches
- Separating analytical and operational data
Lab: A data ownership map for an order domain and a migration plan from a legacy database.
05
Security architecture
Build security into the design, not on top of it.
- Threat modelling (STRIDE)
- Authentication, authorisation and OAuth 2.0 / OIDC flows
- Trust boundaries and network segmentation
- Secrets management and encryption
- Checking against the OWASP API Security Top 10
Lab: For a given solution, a trust boundary diagram, a threat list and mitigations.
06
Cloud, resilience and cost trade-offs
Connect deployment model, resilience and cost to requirements.
- Managed service versus self-operated trade-off
- Multi-zone resilience, RTO and RPO
- Cost of complexity and vendor dependency
- Capacity and cost modelling
- Observability requirements in the architecture
Lab: A resilience and cost trade-off table for two deployment options (numbers recorded as assumptions).
07
Documentation with C4 and ADRs
Keep architecture clear for different audiences and easy to update.
- C4: context, container and component levels
- What to show and not show at each level
- How ADRs and diagrams relate
- Keeping documentation current and owned
- Dynamic and deployment diagrams
Lab: A set of C4 diagrams from context to component for a case study.
08
Architecture reviews and working with delivery teams
Carry an architectural decision to the team and protect it during delivery.
- Architecture review formats and criteria
- A lightweight ATAM-style approach
- Fitness functions and automated checks
- Collaborating with the delivery team
- Managing decision drift
Lab: Run a mock architecture review of another participant's solution and write up the result.