Description and Communication of Software Architectures
Domain 3: Description and communication of software architectures
This domain tests whether you can document and present architecture so that different stakeholders can understand and act on it. The exam emphasizes purpose-driven views, consistent notation, clear interfaces, and decisions with rationale. It is not a drawing contest; it is a communication and traceability discipline.
Core rules
- Choose views by stakeholder question: context for scope and neighbors, building-block for responsibilities, runtime for scenarios, deployment for infrastructure mapping.
- Use a consistent notation, often UML or a clearly defined box-and-line style; label elements and relationships.
- Document interfaces with semantics, data, protocols, errors, and quality expectations, not just names.
- Record architecture decisions as ADRs with status, context, decision, alternatives, and consequences.
- Keep models and text consistent; a diagram without explanation is ambiguous.
- Tailor detail: management needs risks and costs; developers need contracts and dependencies.
Worked example
A payment service must be explained to security and to management. For security, the architect shows a runtime view: browser to API gateway, payment service, tokenization provider, and audit log, with TLS and trust boundaries marked. For management, a one-page context view shows the service boundary, external provider dependency, and the risk of provider outage. Both views derive from the same model. Reasoning: the views answer different questions while remaining consistent. The architect adds an ADR explaining why card data never enters the core system.
Traps
One all-purpose diagram fails. Unlabeled arrows, mixed notation, and missing interface semantics cost marks. Do not present decisions as facts without alternatives. Do not let documentation drift from the implemented system. Avoid dumping code-level detail into an architecture view.