Learn architecture documentation vocabulary: 4+1 view model, logical vs. physical architecture, ADRs, arc42 template, deployment diagrams — the language of professional architecture documentation.
0 / 22 completed
1 / 22
The architect says: 'We follow the 4+1 view model for our architecture documentation.' What is the '4+1 view model'?
The 4+1 view model, introduced by Philippe Kruchten, describes software architecture through five views: Logical (functionality), Process (dynamic behaviour), Development (code organisation), Physical (deployment), and Scenarios (+1 use cases that tie the other views together). It is widely used in enterprise architecture documentation.
2 / 22
The tech lead explains: 'The logical architecture shows the components and their relationships, while the physical architecture shows where they run.' What is the key difference?
Logical architecture focuses on the conceptual structure — components, layers, modules, and their relationships — independent of infrastructure. Physical architecture (also called deployment architecture) shows where components actually run: which servers, containers, cloud regions, and networks. Both views are necessary for a complete architectural picture.
3 / 22
A developer says: 'The architecture is documented in the ADR for this decision.' What is an ADR?
ADR stands for Architecture Decision Record. An ADR is a short document that captures a significant architectural decision, its context, the options considered, the chosen solution, and the rationale. ADRs are stored in the repository alongside the code (often in /docs/adr/) and provide a historical record of why the architecture looks the way it does.
4 / 22
The architect recommends: 'We use the arc42 template for documenting our system.' What is arc42?
arc42 is a pragmatic, structured template for documenting software architectures. It organises documentation into 12 sections, including system context, constraints, solution strategy, building block view, runtime view, deployment view, and architectural decisions. It is widely adopted in German-speaking countries and increasingly used internationally.
5 / 22
During a review, the engineer says: 'The deployment diagram shows we have two app servers behind a load balancer with a shared database.' What does a deployment diagram show?
A deployment diagram (a UML artefact, also Level 4 in C4 model terms) shows the physical or virtual infrastructure: nodes (servers, VMs, containers, devices), communication paths (networks, protocols), and which software components are deployed on which nodes. It is essential for understanding availability, scaling, and infrastructure dependencies.
6 / 22
PR Description:
"Fix: Updated API endpoint to handle user authentication. This change utilizes the new OAuth2 flow as outlined in the architecture document. The previous implementation was vulnerable to brute-force attacks due to a lack of rate limiting."
This question assesses understanding of how architecture documentation informs development work. The correct answer emphasizes that a good PR description connects the code change to its architectural context – in this case, referencing the document and highlighting security implications. It corrects the misconception that PR descriptions should only detail code modifications; integrating architectural considerations is crucial for maintainability and consistency.
7 / 22
Sarah: "Hey team, I'm working on the new microservice for order processing. The architecture document mentions a 'bounded context' for orders. Can someone explain what that means in practice? It seems like just another buzzword."
Bounded contexts are a crucial architectural concept that helps manage complexity in microservices. Essentially, each bounded context represents a single business domain with its own data model and logic, minimizing dependencies between services. This contrasts with having a monolithic database containing all order-related information, which would be prone to conflicts and difficult to evolve independently – the key is clear boundaries around responsibility.
8 / 22
David asks during a code review: "The architecture document mentions 'domain model'. What does that specifically refer to in this context – is it just the data structure or something more?" Consider the following options for responding to David.
David's question highlights a common misunderstanding of 'domain model'. It's not *just* about the database schema (option A); it represents the core business concepts and their relationships. The domain model captures the 'what' of the business – the rules and processes – rather than merely the 'how' represented by the data structure (options C & D). Option B is a more accurate description, emphasizing the conceptual nature of the model.
9 / 22
PR Description:
"Fix: Updated API endpoint to handle user authentication. This change utilizes the new OAuth2 flow as outlined in the architecture document. The previous implementation was vulnerable to brute-force attacks due to a lack of rate limiting."
This question assesses understanding of how architecture documentation informs development work. The correct answer emphasizes that a good PR description connects the code change to its architectural context – in this case, referencing the document and highlighting security implications. It corrects the misconception that PR descriptions should only detail code modifications; integrating architectural considerations is crucial for maintainability and consistency.
10 / 22
Sarah: "Hey team, I'm working on the new microservice for order processing. The architecture document mentions a 'bounded context' for orders. Can someone explain what that means in practice? It seems like just another buzzword."
Bounded contexts are a crucial architectural concept that helps manage complexity in microservices. Essentially, each bounded context represents a single business domain with its own data model and logic, minimizing dependencies between services. This contrasts with having a monolithic database containing all order-related information, which would be prone to conflicts and difficult to evolve independently – the key is clear boundaries around responsibility.
11 / 22
David asks during a code review: "The architecture document mentions 'domain model'. What does that specifically refer to in this context – is it just the data structure or something more?" Consider the following options for responding to David.
David's question highlights a common misunderstanding of 'domain model'. It's not *just* about the database schema (option A); it represents the core business concepts and their relationships. The domain model captures the 'what' of the business – the rules and processes – rather than merely the 'how' represented by the data structure (options C & D). Option B is a more accurate description, emphasizing the conceptual nature of the model.
12 / 22
PR Description:
"Fix: Updated API endpoint to handle user authentication. This change utilizes the new OAuth2 flow as outlined in the architecture document. The previous implementation was vulnerable to brute-force attacks due to a lack of rate limiting."
This question assesses understanding of how architecture documentation informs development work. The correct answer emphasizes that a good PR description connects the code change to its architectural context – in this case, referencing the document and highlighting security implications. It corrects the misconception that PR descriptions should only detail code modifications; integrating architectural considerations is crucial for maintainability and consistency.
13 / 22
Sarah: "Hey team, I'm working on the new microservice for order processing. The architecture document mentions a 'bounded context' for orders. Can someone explain what that means in practice? It seems like just another buzzword."
Bounded contexts are a crucial architectural concept that helps manage complexity in microservices. Essentially, each bounded context represents a single business domain with its own data model and logic, minimizing dependencies between services. This contrasts with having a monolithic database containing all order-related information, which would be prone to conflicts and difficult to evolve independently – the key is clear boundaries around responsibility.
14 / 22
David asks during a code review: "The architecture document mentions 'domain model'. What does that specifically refer to in this context – is it just the data structure or something more?" Consider the following options for responding to David.
David's question highlights a common misunderstanding of 'domain model'. It's not *just* about the database schema (option A); it represents the core business concepts and their relationships. The domain model captures the 'what' of the business – the rules and processes – rather than merely the 'how' represented by the data structure (options C & D). Option B is a more accurate description, emphasizing the conceptual nature of the model.
15 / 22
PR Description:
"Fix: Updated API endpoint to handle user authentication. This change utilizes the new OAuth2 flow as outlined in the architecture document. The previous implementation was vulnerable to brute-force attacks due to a lack of rate limiting."
This question assesses understanding of how architecture documentation informs development work. The correct answer emphasizes that a good PR description connects the code change to its architectural context – in this case, referencing the document and highlighting security implications. It corrects the misconception that PR descriptions should only detail code modifications; integrating architectural considerations is crucial for maintainability and consistency.
16 / 22
Sarah: "Hey team, I'm working on the new microservice for order processing. The architecture document mentions a 'bounded context' for orders. Can someone explain what that means in practice? It seems like just another buzzword."
Bounded contexts are a crucial architectural concept that helps manage complexity in microservices. Essentially, each bounded context represents a single business domain with its own data model and logic, minimizing dependencies between services. This contrasts with having a monolithic database containing all order-related information, which would be prone to conflicts and difficult to evolve independently – the key is clear boundaries around responsibility.
17 / 22
David asks during a code review: "The architecture document mentions 'domain model'. What does that specifically refer to in this context – is it just the data structure or something more?" Consider the following options for responding to David.
David's question highlights a common misunderstanding of 'domain model'. It's not *just* about the database schema (option A); it represents the core business concepts and their relationships. The domain model captures the 'what' of the business – the rules and processes – rather than merely the 'how' represented by the data structure (options C & D). Option B is a more accurate description, emphasizing the conceptual nature of the model.
18 / 22
During a standup meeting, Mark says: 'We're using a 'spike' to investigate the feasibility of implementing event sourcing. The architecture document references it.' What does a 'spike' typically represent in architectural documentation?
Spikes are temporary investigations or proof-of-concepts used to quickly answer a specific question and reduce risk. They're not formal designs; instead, they're meant for rapid experimentation. The architecture document referencing it suggests the spike was used to inform architectural decisions, focusing on feasibility.
19 / 22
Liam sends this Slack message: 'Hey team, I'm reviewing the API documentation. It mentions 'API Gateway' and says we should use it to manage all external requests. What's the primary benefit of using an API gateway in our architecture?'
An API gateway serves as a central control point for all incoming requests. This allows for crucial functions like authentication (verifying user identity), rate limiting (preventing abuse), and routing requests to the appropriate backend services – significantly simplifying external interaction compared to each service handling this independently.
20 / 22
In a code review comment, Elena asks: 'The architecture document describes 'Service Mesh'. Can you elaborate on how it integrates with our microservices and what its key responsibilities are?'
A Service Mesh isn't about building services; it's an infrastructure layer that manages service-to-service communication. It handles crucial aspects like traffic management (routing and load balancing), security (encryption and authentication), and observability (metrics and tracing) – all without requiring changes to the application code itself.
21 / 22
A PR description reads: 'Implemented a new caching layer using Redis. The architecture document defines this as part of our 'data tier'. What is the primary purpose of the 'data tier' in architectural documentation?
The 'data tier' is a fundamental component in architectural descriptions, defining the layer responsible for storing and retrieving data. This typically includes databases, caching systems, and other components directly involved in data management – providing a clear separation of concerns within the application architecture.
22 / 22
During a discussion about system design, David says: 'We're using 'CQRS' (Command Query Responsibility Segregation) as described in the architecture document. What does this pattern fundamentally aim to achieve?'
CQRS is a pattern that separates command (write) operations from query (read) operations. This allows you to optimize each side independently – for example, using a highly scalable database for reads and a more traditional one for writes. Separating these responsibilities greatly improves performance and scalability.
What will I practice in "Architecture Documentation Vocabulary"?
This is an Architecture Diagrams exercise set. It walks through 22 scenario-based multiple-choice questions built around real usage of Architecture Diagrams terminology that IT professionals encounter on the job.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to complete with no account, sign-up, or paywall.
How many questions are in this exercise?
This set contains 22 questions. Each one shows immediate feedback and a detailed explanation after you answer, so you learn the correct usage right away rather than waiting for a final score.
Do I need prior experience to complete this exercise?
No prior experience is required. Each question includes a full explanation covering the reasoning behind the correct answer, so the exercise itself teaches the Architecture Diagrams vocabulary as you go.
Can I retry the exercise if I get questions wrong?
Yes — use the "Try again" button on the results screen to reset your answers and go through all the questions again. There is no limit on attempts.
Is my progress saved?
Your answers and score for the current session are tracked in the browser as you go. No account or login is needed, and there is nothing to install.
What if I don't understand a term used in a question?
Read the explanation shown after you answer each question — it breaks down the correct term in plain English with a real-world example. You can also check the site Glossary for quick definitions.
How is this different from reading a blog article on the topic?
Exercises like this one are interactive drills that test and reinforce specific vocabulary through multiple-choice questions, while blog articles explain concepts in prose. Practising here after reading builds active recall, not just passive recognition.
Where can I find more Architecture Diagrams exercises?
See the Architecture Diagrams exercises hub for the full set of related pages, or browse all exercise categories from the main Exercises index.
Can I use this exercise to prepare for a technical interview?
Yes — Architecture Diagrams vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.