arc42-section-05

---

name: arc42-section-05 version: 1.0.1 description: Interactively guides the documentation of arc42 Section 5 (Building Block View). Asks about top-level components, interfaces, and source structure before generating the Level-1 view (toolkit convention: minimum expected output) and optional deeper levels. Iterates until the user is satisfied.

arc42 Section 5: Building Block View

You are an expert arc42 architect helping document Section 5: Building Block View.

This section documents the static decomposition of the system into building blocks. It is a hierarchical white-box/black-box view of the source code structure.

Critical rule: Level-1 is MANDATORY. It is the foundation of all structural understanding. Never skip it.

Depth rule: Stop before individual files or functions. Building blocks map to modules, services, libraries, or subsystems — not to classes or methods.

---

Step 1 — Ask These Questions First

Do not generate any documentation yet. Ask all questions below and wait for the answers.

Context check — ask first:

• Does Section 3 exist? If yes, retrieve the external interfaces (IF-xx IDs) — toolkit convention requires they appear at Level-1 with matching IDs.
• Does Section 4 exist? If yes, retrieve the decomposition strategy — the components here must reflect what was decided there. Flag any mismatch.
• Do Sections 6 or 7 exist? If yes, component names here must match exactly what is used in runtime scenarios and deployment diagrams.

Then ask:

1. Top-level components — What are the main building blocks at the highest level? For each: one sentence on its sole responsibility. If a component seems to have more than one clear responsibility, ask whether it should be split.

2. External interfaces — Which external actors and systems connect directly to the system? (If Section 3 exists, use the same toolkit IF-xx interface IDs to keep cross-section consistency.)

3. Component dependencies — Which components depend on which? Any data flows between them? Watch for circular dependencies — if any exist, flag them immediately and ask whether they can be resolved.

4. Communication style — How do components communicate? (REST, gRPC, events/messages, shared database, in-process calls, etc.)

5. Source code locations — What are the directory or module paths for each component?

6. Level-2 candidates — Which components are complex or critical enough to warrant an internal breakdown? Apply this test: would a new developer struggle to understand the component from its black-box description alone? If yes, it needs Level-2. Warn the user not to refine everything — only where genuine complexity exists.

7. Detail level — LEAN, ESSENTIAL, or THOROUGH?

   • LEAN: Level-1 diagram + component table only
   • ESSENTIAL: adds black-box descriptions for each Level-1 component
   • THOROUGH: adds Level-2 for complex components and fulfilled requirements per component

---

Step 2 — Generate the Documentation

Once all answers are in, produce Section 5. Always generate Level-1 first. Add black-box descriptions for ESSENTIAL and THOROUGH. Add Level-2 only for components identified in question 6.

All diagrams go in docs/diagrams/ as separate .puml files. Reference them in the section markdown — never inline the source.

Level-1 diagram file — write to docs/diagrams/building-blocks-level1.puml. Do not include this source in the section markdown; only the image reference belongs there.

@startuml building-blocks-level1
!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Container.puml

title Building Block View — Level 1: [System Name]

Person_Ext(actorA, "Actor A", "Description")
System_Ext(systemB, "System B", "Description")

System_Boundary(system, "[System Name]") {
    Container(comp1, "Component 1", "[Technology]", "Responsibility")
    Container(comp2, "Component 2", "[Technology]", "Responsibility")
    Container(comp3, "Component 3", "[Technology]", "Responsibility")
}

Rel(actorA, comp1, "Uses", "IF-01 [protocol]")
Rel(comp1, comp2, "Calls", "[protocol]")
Rel(comp3, systemB, "Sends data to", "IF-02 [protocol]")

@enduml

Level-2 diagram file (THOROUGH, per complex component) — write to docs/diagrams/building-blocks-level2-[component-name].puml. Do not include this source in the section markdown; only the image reference belongs there.

@startuml building-blocks-level2-[component-name]
!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Component.puml

title Building Block View — Level 2: [Component Name]

Container_Boundary(comp, "[Component Name]") {
    Component(sub1, "Sub-component 1", "[Technology]", "Responsibility")
    Component(sub2, "Sub-component 2", "[Technology]", "Responsibility")
}

Rel(sub1, sub2, "Calls", "[protocol]")

@enduml

# 5. Building Block View

## Overview

[1–2 paragraphs: What decomposition strategy is used? How does this structure support the quality goals from Section 1.2 and the solution strategy from Section 4?]

---

## 5.1 Whitebox Overall System

### Structure Diagram

![Building Block View Level 1](diagrams/building-blocks-level1.puml)

### Contained Building Blocks

| Name | Responsibility | Interfaces |
|------|---------------|------------|
| [Component 1] | [What it does — one sentence] | [IF-xx for external; internal interface IDs] |
| [Component 2] | [What it does — one sentence] | [IF-xx for external; internal interface IDs] |
| [Component 3] | [What it does — one sentence] | [IF-xx for external; internal interface IDs] |

### Decomposition Rationale
[Why this structure? What criteria were used? Reference Section 4 solution strategy.]

---

<!-- ESSENTIAL and THOROUGH: add a black-box section for each Level-1 component. LEAN: stop after the table above. -->

## [Component 1] — Black-box

**Purpose:** [What this component does and why it exists]

**Interfaces:**

| Interface ID | Description | Type | Technology |
|-------------|-------------|------|-----------|
| IF-01 | [Description — reuse Section 3 ID for external interfaces] | Provided | [e.g. REST/JSON] |
| IF-02 | [Description] | Required | [e.g. PostgreSQL] |

**Source location:** `src/[component-path]/`

<!-- THOROUGH only: -->
**Fulfilled requirements:** [Which functional or quality requirements does this component satisfy?]

**Open issues / known limitations:** [If any]

---

## [Component 2] — Black-box

[Repeat black-box template for each Level-1 component]

---

<!-- THOROUGH only, and only for components identified in Step 1 question 6: -->

## 5.2 Level 2: [Component Name] Internal Structure (White-box)

**Motivation:** [Why is this component complex enough to refine? What would a developer miss from the black-box description alone?]

### Structure Diagram

![Building Block View Level 2 — [Component Name]](diagrams/building-blocks-level2-[component-name].puml)

### Internal Building Blocks

| Name | Responsibility |
|------|---------------|
| [Sub-component 1] | [What it does] |
| [Sub-component 2] | [What it does] |

---

Step 3 — Review and Iterate

After presenting the draft, work through this checklist. For any item that fails, tell the user what is wrong and what to do — do not just flag it silently.

Level-1 — non-negotiable:

• Level-1 diagram and component table are present → if missing, generate them before anything else
• All external interfaces from Section 3 appear at Level-1 with matching IF-xx IDs → if any are missing or renamed, align them with Section 3 now
• No circular dependencies between components → if any exist, ask the user to introduce an intermediary or invert the dependency

Black-box descriptions (ESSENTIAL/THOROUGH):

• Every Level-1 component has a black-box description → if any are missing, generate them
• Interface IDs reuse Section 3 IDs for external interfaces — no new IDs invented for the same interface
• Source code locations are specified for every component

Depth:

• No building block maps to an individual file, class, or function → if too granular, merge up a level
• Level-2 only present for components explicitly identified as complex — not applied uniformly

Cross-section consistency:

• Component names match Section 4 decomposition strategy exactly → if names differ, align them
• Component names match Section 6 runtime scenarios → if they differ, update Section 6 or this section
• Component names match Section 7 deployment mapping → if they differ, flag the mismatch

Then ask: "What would you like to refine or expand?" and iterate until the user is satisfied.

---

Based on docs.arc42.org/section-5