Software Architecture Design and Modeling
This domain tests how you move from drivers to structures: identifying architecturally significant requirements, selecting styles, patterns and tactics, and expressing the result in models that belong to defined viewpoints.
Core rules and concepts
- Design starts from architecturally significant requirements, usually quality attribute scenarios with stimulus, response and measure, not from a preferred pattern.
- Style families each carry known trade-offs: layered, pipes and filters, client-server, publish-subscribe, event-driven, microservices, CQRS, ports and adapters.
- A tactic targets one quality attribute, for example heartbeat for availability or introducing concurrency for performance. A pattern bundles several tactics plus constraints, so choosing a pattern means accepting its costs.
- Model kinds are chosen per viewpoint: UML component, sequence, state machine and deployment diagrams, SysML blocks, or architectural description languages. Correspondence rules keep views consistent.
- Preserve options: postpone irreversible decisions such as platform choice or data ownership until the last responsible moment.
Worked example
A five-person team builds an internal claims tracker with three releases per quarter and one partner integration. Candidate A is microservices per domain; candidate B is a modular monolith with explicit ports and adapters. Drivers: independent deployability has low value at this team size, operational maturity is low, modifiability is high. Microservices would convert design-time coupling into operational coupling, requiring service discovery, tracing and distributed data consistency that this team cannot sustain. The modular monolith keeps boundaries enforceable through dependency tests and allows later extraction. The decision is recorded with an explicit revisit trigger: more than three teams, or a genuine independent scaling need.
Traps that cost marks
- Pattern-first design, where the pattern is the goal rather than a response to a driver.
- Building a distributed monolith: service boundaries with none of the operational or organisational benefits.
- Selecting a style that assumes platform capability the organisation does not have.
- Modelling every view exhaustively before any code, and ignoring rejected alternatives in the rationale.