Basics of Software Architecture
Domain 1: Basics of software architecture
This domain tests whether you can define software architecture precisely and distinguish it from surrounding activities. The exam expects you to recognize architecture as the set of significant structures and decisions: building blocks, their externally visible interfaces, and the rules that govern how they collaborate. Architecture is shaped by functional requirements but driven strongly by quality attributes and constraints.
Core rules
- A building block is a unit of decomposition; an interface is a contract, not merely a method signature.
- Views separate concerns: context, building-block, runtime, and deployment views answer different stakeholder questions.
- Architecture decisions are significant when they are costly to change and constrain many later decisions.
- Constraints come from technology, organization, standards, budget, and legacy systems; they are not optional preferences.
- Architecture differs from detailed design by scope and significance, not by drawing style.
Worked example
An online shop needs checkout. A candidate proposes a single CheckoutManager class with database access, payment calls, and email sending. The architect instead defines three building blocks: Checkout, PaymentGateway, and Notification. PaymentGateway exposes a stable interface and hides provider details; Notification consumes events. The reasoning is architectural because it fixes boundaries, dependency direction, and replaceability, and it supports testability and provider substitution. Class-level algorithms remain detailed design.
Traps
Do not call every diagram an architecture. Do not list patterns without showing which quality attribute they serve. Do not ignore constraints such as an existing ERP system. Do not confuse architecture with project plan or code structure alone. State decisions and rationale, not only boxes.