Software Design and Architecture
What the domain covers
This domain tests architectural structures, design principles, patterns, and quality-attribute tradeoffs. Expect questions on architectural styles, views, coupling and cohesion, SOLID and GRASP, design patterns, and architecture evaluation.
Core rules
- Architecture concerns system-wide structure and quality attributes; detailed design concerns local module responsibilities and interfaces.
- Use multiple views, such as logical, process, development, and deployment, because one view cannot capture all concerns.
- Aim for high cohesion and low coupling, but recognize that distribution adds latency, partial failure, and operational cost.
- Patterns are context-dependent solutions; name the problem, forces, and tradeoffs, not just the pattern name.
Worked example
Requirement: “Independent teams must deploy features without coordinating releases, and one module’s load must not degrade others.” A monolith scores poorly on independent deployability and selective scaling. Microservices fit the deployment and scaling forces, but introduce network calls, eventual consistency, and observability overhead. Reasoning: the decision is justified by explicit quality-attribute scenarios, not by fashion. A modular monolith may be better if the team is small and consistency is critical.
Traps
- Confusing architecture with detailed class design.
- Applying a pattern without stating the forces it resolves.
- Ignoring operational consequences of distribution.
- Designing for imagined future scale instead of stated scenarios.
Exam focus
Be ready to compare styles and justify a choice using quality attributes.