Software architecture Study Guide

📖 Core Concepts Software Architecture – The set of structures (elements, their relations, and properties) that let us reason about a system; acts as a blueprint like a building’s plan. Architectural Decision – A high‑impact, costly‑to‑change structural choice that shapes the whole system. Architectural Style – A high‑level organization of components and connectors (e.g., layered, microservices, event‑driven). Architectural Pattern – A reusable solution to a recurring system‑level problem (e.g., MVC, Circuit Breaker). Fitness Function – Continuous metric(s) used to check if the architecture meets its quality goals. Stakeholder Diversity – Architects must balance concerns of managers, users, operators, etc. Conway’s Law – Systems tend to mirror the communication structure of the organization that builds them. 4+1 View Model – Logical, Development, Process, Physical, and Scenario (use‑case) views that together document an architecture. 📌 Must Remember Trade‑off Principle: Everything in software architecture is a trade‑off. Why > How: Purpose (“why”) outranks implementation details (“how”). Last Responsible Moment: Delay a decision only until enough information exists to make a justified choice. Architecture Erosion: The gap that forms between intended architecture and actual implementation over time. Key Quality Attributes: Fault tolerance, extensibility, reliability, maintainability, availability, security, performance, usability. ATAM / TARA: Primary techniques for Architecture Tradeoff Analysis. Architecture Decision Record (ADR): Centralized, versioned documentation of each major decision. Twin Peaks Model: Parallel, iterative refinement of requirements and architecture. 🔄 Key Processes Architectural Analysis Gather stakeholder requirements → identify architecturally significant requirements (ASRs) → document functional & quality attributes. Architectural Synthesis (Design) Map ASRs to high‑level components, select styles/patterns, produce initial diagrams (C4, 4+1). Architectural Evaluation Apply ATAM/TARA → score trade‑offs → generate fitness‑function results → decide if redesign needed. Decision‑Making Workflow Context capture → problem formulation → enumerate options → assess trade‑offs → record decision in ADR. Architecture Evolution Monitor fitness functions → detect erosion → apply refactoring/redesign → update documentation. Erosion Detection Consistency‑based (structure vs docs) → Evolution‑based (change patterns) → Defect‑based (bugs linked to architectural violations) → Decision‑based (missing ADRs). 🔍 Key Comparisons Style vs. Pattern Style: high‑level structural organization (e.g., layered). Pattern: concrete solution to a recurring problem within a style (e.g., DAO pattern in a layered architecture). Architecture vs. Detailed Design Architecture: non‑local, high‑impact decisions affecting the whole system. Detailed Design: local, implementation‑level choices (class internals, algorithms). Decision‑Avoidance vs. Last Responsible Moment Avoidance: postponing decisions out of fear → analysis paralysis. Last Responsible Moment: intentional postponement until justification is available. C4 Model vs. 4+1 View Model C4: lightweight, focuses on containers, components, code, and relationships. 4+1: richer set of views, adds development, process, and scenario perspectives. ⚠️ Common Misunderstandings “Architecture is only diagrams.” → Architecture also includes rationales, fitness functions, and documented decisions. “Big Design Up‑Front (BDUF) is always required.” → Agile practices favor “just enough” design; excessive upfront work can increase risk. “Conway’s Law is a rule you must follow.” → It’s an observation; you can reorganize teams to shape architecture deliberately. “All non‑functional requirements are the same as quality attributes.” → Quality attributes are the properties (e.g., performance) that NFRs aim to achieve. 🧠 Mental Models / Intuition Blueprint Analogy: Think of architecture as an architect’s blueprint—showing what goes where, not the exact how each wall is painted. Trade‑off Thermometer: Every decision raises one quality attribute while lowering another; the goal is a balanced “temperature” that meets stakeholder priorities. Erosion as Rust: Small, unnoticed violations are like rust; over time they corrode the intended structure unless inspected and treated. 🚩 Exceptions & Edge Cases When a fitness function cannot be quantified – Use proxy metrics (e.g., response time percentile) or qualitative assessments. Highly regulated domains – May require stricter documentation (formal ADRs, audit trails) beyond “just enough” C4 diagrams. Microservices in a small team – The overhead of service boundaries can outweigh scalability benefits; consider a layered monolith instead. 📍 When to Use Which Choose a Style: Layered → Strong separation of concerns, easy to test, suitable for stable, vertically integrated systems. Microservices → Need independent deployment, high scalability, bounded contexts, and a DevOps culture. Event‑Driven → Loose coupling, asynchronous processing, complex integration scenarios. Select a Documentation Model: C4 → Quick, team‑level communication; early stages or agile environments. 4+1 → Comprehensive stakeholder communication; compliance or large‑scale projects. Apply Evaluation Technique: ATAM → When many quality attributes and stakeholder trade‑offs need structured analysis. TARA → When security‑focused trade‑offs dominate. 👀 Patterns to Recognize Repeated “Why > How” statements → Indicates a quality‑driven decision. References to “high‑impact decisions early” → Spot questions about architectural trade‑offs. Mentions of “fitness function” → Look for metrics or continuous evaluation cues. Erosion Symptoms: mismatched documentation, frequent architectural violations, rising technical debt. 🗂️ Exam Traps Confusing “Style” with “Pattern.” → Test‑writers may list “Layered” as a pattern; remember it’s a style. Assuming all non‑functional requirements are covered by a single quality attribute. – Each NFR maps to a specific attribute (e.g., “fast response” → performance). Choosing ATAM for a security‑only assessment. – ATAM is broad; TARA is the tighter fit for security‑centric trade‑offs. Over‑relying on the “last responsible moment” to delay all decisions. – The principle is when you have enough info, not always postpone. Thinking architecture erosion is caused only by code changes. – Violations, missing ADRs, and knowledge loss are equally culpable.