arc42 section 7: Deployment View

Technical infrastructure and mapping of building blocks to it

• A small set of scenarios or use cases illustrates the architecture as a fifth view. → 4+1 View Model
• If the software runs as a distributed system, the document includes a deployment view of the technical infrastructure. → Additional Architecture Viewpoints (Security, Information, Operational, Development, Process, Evolution)
• Operation, administration and support in production are described. → Additional Architecture Viewpoints (Security, Information, Operational, Development, Process, Evolution)
• The building block view is present and shows the static decomposition of the system. → Architectural View
• If 4+1 is used, a small set of scenarios is included to illustrate the architecture. → Architecture View Model
• Quality perspectives are applied to views, not treated as views of their own. → Architecture Viewpoint
• The document maps building blocks onto hardware. → Deployment View
• If the system runs in several environments, each relevant environment is documented. → Deployment View
• The deployment view uses a UML deployment diagram. → Deployment View
• Where readable Git diffs matter, the team uses plain .drawio files instead of .drawio.png. → Diagram Metadata in PNG (drawio.png)
• The deployment view documents which building blocks run on which hardware or infrastructure. → Distribution View Antipatterns
• All relevant environments are documented. → Distribution View Antipatterns
• Each deployment diagram covers a single environment, such as production or staging. → Distribution View Antipatterns
• The documentation states whether diagrams are rendered with the free public Kroki service or a self-managed instance. → Kroki
• If POST with plain text is used, the output format is chosen with the Accept header. → Kroki
• The conventions for each view type (viewpoint) are defined apart from the views themselves. → Model vs. View
• High-level and low-level views are drawn as separate diagrams, not combined in one. → Unclear Level of Abstraction Antipattern
• Applications are mapped to technology platforms. → Application Architecture Artifacts
• Business objects can be traced through data objects to the artifacts that realize them. → Enterprise Architecture Layers
• Each technology has a lifecycle status such as adopt, tolerate, invest, or retire. → IT Component Catalogue
• Every relevant environment is documented, not just production. → Technology Architecture
• The document states how partial failure of a service or server is handled. → Connectors and Distribution
• Every deployment targets a node, and only artifacts (or artifact instances) are deployed onto it. → Deployment Diagram Modeling Mistake
• Physical hardware nodes are marked «device». Software hosts such as an application server or JVM are marked «executionEnvironment». → Deployment Diagram Modeling Mistake
• Each connection between nodes is labeled with its protocol, such as JDBC, REST or RMI. → Deployment Diagram Modeling Mistake
• The deployment view shows infrastructure nodes and channels, whether in a UML deployment diagram or another notation. → Matching Diagram Type to System Aspect
• Diagrams that show flow of control and data are treated as interaction diagrams, a subset of behavior diagrams. → UML 2.5 Diagram Taxonomy
• Artifacts are drawn as rectangles inside the box of the node they are allocated to. → UML Deployment Diagram
• Complex infrastructure is documented with nested diagrams or nested nodes. → UML Deployment Diagram
• Each environment that needs it (development, test, production) has its own deployment documentation. → UML Deployment Diagram
• Every relationship line is labeled, and the label matches its direction and intent. → UML Modeling Anti-Pattern
• Deeper levels zoom into selected building blocks of the level above. → UML Structure Diagram
• The documentation does not claim that using UML by itself improves the architecture. → Why Use UML in Architecture Documentation
• The availability calculation includes external services that affect critical flows. → Availability
• Installability goals cover both installing and uninstalling, not installing alone. → Installability
• Recovery targets are defined per incident (RTO) and for acceptable data loss (RPO). → Recoverability
• The document describes the failover logic and split-brain prevention, and says how they are exercised. → Active Redundancy
• Traffic is encrypted in transit, for example with TLS. → Encrypt Data
• The document states how a failed release is rolled back to an earlier version. → Integrability, Deployability, Testability and Reliability Tactics
• The document states whether the balancer works at Layer 4 or Layer 7 and why. → Load Balancer
• Timeouts and failure thresholds are configured so transient failures such as network delays do not trigger unnecessary actions. → Ping/Echo
• The document describes how failures are detected (for example heartbeat, ping/echo, or voting) and any grace period used. → Redundant Spare