System Design and Architecture
Domain 4 tests whether you can decompose a system into modules with the right coupling and cohesion, select an architectural style against quality attributes, and name the pattern that solves a stated problem.
Modular design
- Coupling, best to worst: data, stamp, control, external, common, content. Aim for data coupling: modules exchange only the parameters they need.
- Cohesion, worst to best: coincidental, logical, temporal, procedural, communicational, sequential, functional. Aim for functional cohesion: one module, one well-defined task.
- Information hiding (Parnas) says modules should hide design decisions likely to change. Fan-in counts callers; fan-out counts callees. High fan-in with moderate fan-out is generally healthy.
Architectural styles
- Layered: dependencies between adjacent layers, easy substitution, performance cost when crossing layers.
- Pipe-and-filter: independent filters transforming streams; strong for compilers and batch pipelines, weak for interactive control.
- Repository and blackboard: shared data store with independent tools; blackboard suits ill-structured problems such as signal interpretation.
- Client-server, MVC (model holds state and logic, view renders, controller handles input), SOA with services and an ESB, and microservices with independent deployment, bounded contexts and eventual consistency.
- Quality-attribute tactics: heartbeat and redundancy for availability, caching and concurrency for performance, publish-subscribe for modifiability, authentication and authorisation for security. ATAM evaluates trade-offs through quality scenarios.
Patterns
Creational: Factory Method, Abstract Factory, Builder, Singleton. Structural: Adapter, Facade, Proxy, Decorator, Composite, Bridge. Behavioural: Observer, Strategy, Template Method, Command, State. Strategy swaps algorithms chosen by the client; State changes behaviour as the object's internal state changes.
Worked example
A module computes an invoice total, writes it into a global customer record, and sets the caller's error flag. Writing to a global record is common coupling because modules share mutable global data; setting the caller's flag is control coupling because control information passes between modules. Refactor: pass an invoice object, return a result object for data coupling, and keep the total calculation in its own functionally cohesive module.
Traps
- Ranking stamp coupling below control coupling; the correct order is data, stamp, control.
- Calling a temporal module that initialises several subsystems highly cohesive.
- Confusing the MVC controller with the model.
- Recommending microservices without acknowledging distributed transactions and operational overhead.