Architecture and Quality
Domain 5: Architecture and quality
This domain tests whether you can make quality attributes concrete and evaluate whether an architecture supports them. The exam expects quality scenarios, tactics, trade-offs, and evaluation methods rather than vague claims such as secure or fast.
Core rules
- Quality attributes are non-functional properties such as performance, availability, modifiability, security, usability, and testability.
- Use ISO/IEC 25010-style categories to structure discussion, but define project-specific scenarios.
- A quality scenario has source, stimulus, environment, artifact, response, and response measure.
- Tactics are design decisions that influence a quality attribute: redundancy for availability, caching for performance, abstraction for modifiability.
- Quality attributes trade off; document the trade-off and the accepted risk.
- Evaluate early with scenario walkthroughs, prototypes, or structured reviews such as ATAM-style analysis.
Worked example
Requirement: the checkout must be reliable. The architect rewrites it as: when the payment provider is unavailable during peak shopping, checkout returns a clear retry message within two seconds and queues the order for later payment, with no duplicate charge. Tactics include timeout, circuit breaker, idempotency key, and durable queue. The reasoning links stimulus and measurable response to concrete mechanisms, and exposes a trade-off: queued payment improves availability but adds reconciliation complexity.
Traps
Vague ilities cannot be tested. Do not confuse quality assurance with testing alone. Do not optimize one attribute without stating the impact on another. Avoid scenarios with no response measure. Do not present tactics as a checklist without connecting them to the scenario.