Software Design Principles and Architecture
Domain 3 covers design principles (cohesion, coupling, SOLID, information hiding), architectural styles, and the trade-offs between quality attributes. Questions often ask you to spot a principle violation or select a style for a stated constraint.
Principles
- Aim for high cohesion (one unit, one reason to change) and low coupling (few, narrow, stable dependencies).
- Coupling, worst to best: content, common, control, stamp, data.
- Cohesion, best to worst: functional, sequential, communicational, procedural, temporal, logical, coincidental.
- SOLID: Single Responsibility (one reason to change), Open/Closed (extend without modifying), Liskov Substitution (subtypes honour contracts), Interface Segregation (small client-specific interfaces), Dependency Inversion (depend on abstractions, not concretes).
- Information hiding (Parnas): conceal the decisions most likely to change behind stable interfaces.
Architecture
Common styles: layered (strict or relaxed), client-server, MVC, pipe-and-filter, event-driven/pub-sub, microservices and modular monolith. Architecture is evaluated against quality attributes using tactics (caching for performance, replication for availability, queues for scalability). Document it with UML component and deployment diagrams or the C4 model. Microservices buy independent deployability at the cost of network failure modes, distributed data consistency and operational overhead.
Worked example
A class ReportService queries the database, formats HTML, writes a file, sends an email and logs. Reasoning: five distinct reasons to change means a Single Responsibility violation, and the HTML plus SQL make it untestable without a live database, which is high coupling to concretes. Refactor into ReportRepository (persistence), ReportFormatter behind an interface (so adding PDF is extension, satisfying Open/Closed), NotificationSender, with ReportService orchestrating. Cohesion rises because each unit has one axis of change; coupling narrows to stable interfaces. Note that the split is justified by axes of change, not by line count.
Traps that cost marks
- Defending Singleton as a pattern when it is a global with hidden coupling and testing pain.
- Confusing Strategy (interchangeable algorithm selected by the client) with State (behaviour changes as internal state transitions).
- Liskov violations masked by type checks or exceptions thrown in overrides.
- Choosing microservices for fashion while ignoring data consistency and operations cost.
- Abstracting before a second implementation actually exists.