Design and Architecture
This domain tests architecture styles, quality-attribute scenarios, interface contracts, and trade-off reasoning. Expect questions that ask why a style was chosen or which quality attribute a design threatens.
Core concepts
- Architecture is the fundamental organization of a system: elements, relationships, and governing principles. Useful views include logical, process, deployment, and data views.
- Quality attributes drive architecture: performance, availability, security, modifiability, scalability, and testability. Express them as scenarios with stimulus, response, and measure.
- Aim for high cohesion and low coupling. Coupling includes syntactic, semantic, and temporal dependencies, not just code imports.
- Interfaces are contracts covering syntax, semantics, protocols, error behavior, and versioning. Ambiguous interface semantics cause integration failures later.
- Patterns such as layered, event-driven, pipeline, and microservices carry trade-offs; select against prioritized quality scenarios, not fashion.
- Record significant decisions in architecture decision records with context, decision, and consequences.
Worked example
A team needs billing and reporting to deploy independently. A monolith couples their release cycles; microservices add network, data consistency, and operational complexity. If the team is small and operational maturity is low, a modular monolith with clear bounded contexts may satisfy deployability better than premature microservices. The reasoning is explicit: weigh independent deployability against operational cost and data consistency risk, then record the decision and revisit triggers in an ADR.
Traps
- Choosing a pattern by popularity while ignoring team skills and operational cost.
- Designing for unlimited scale when measured demand does not justify it.
- Leaving interface error semantics unspecified.
- Ignoring non-functional scenarios until testing.
- Treating an architecture diagram as the architecture; decisions and rationale matter.