# Component view

A component diagram zooms into a single container and shows its major internal parts. Most teams need this for one or two containers at most, and never for the rest.

Draw it where the internal structure is genuinely difficult, and skip it everywhere else.

---

## When to draw one

* A container with complicated internal structure.
* Explaining a design before implementing it.
* Onboarding onto the part of the system people find hardest.

---

## What is on the diagram

| **Element**         | **Meaning**                                            |
| ------------------- | ------------------------------------------------------ |
| Component           | A grouping of related functionality inside a container |
| Container boundary  | A box around the components                            |
| Relationship        | How components call each other                         |
| External containers | Drawn outside, so the boundaries stay clear            |

---

## A worked example

Inside the Order API, at component level:

![Component view](https://help.gocapable.com/images/att1418100760.svg)

The source, which you can paste into a new diagram and edit:

```
@startuml
!include <C4/C4_Component>

title Components: Order API

Container(web, "Web application", "React")
ContainerDb(db, "Order database", "PostgreSQL")
ContainerQueue(queue, "Job queue", "Redis Streams")
System_Ext(payments, "Payment provider")

Container_Boundary(api, "Order API") {
  Component(ctrl, "Order controller", "Express router", "HTTP endpoints for the order lifecycle")
  Component(svc, "Order service", "Domain service", "Order rules, state transitions and validation")
  Component(price, "Pricing component", "Domain service", "Discounts, tax and totals")
  Component(pay, "Payment adapter", "Adapter", "Talks to the payment provider")
  Component(repo, "Order repository", "Data access", "Reads and writes orders")
  Component(pub, "Job publisher", "Adapter", "Enqueues fulfilment jobs")
}

Rel(web, ctrl, "Calls", "JSON/HTTPS")
Rel(ctrl, svc, "Uses")
Rel(svc, price, "Uses")
Rel(svc, pay, "Uses")
Rel(svc, repo, "Uses")
Rel(svc, pub, "Uses")
Rel(repo, db, "Reads and writes", "SQL")
Rel(pub, queue, "Publishes to")
Rel(pay, payments, "Calls", "HTTPS")
@enduml
```

---

## A few things that catch people out

* Level 3 is optional. Drawing it for every container is how C4 documentation becomes unmaintainable.
* Components are groupings of functionality, not classes. If you are drawing classes, you have gone one level too far.
* Keep other containers outside the boundary so the reader can see where the container ends.

---

## Related

[System context diagramC4 level 1: the system, its users, and the things around it.](https://help.gocapable.com/diagrams/system-context-diagram.html)

[Container diagramC4 level 2: the deployable pieces inside your system.](https://help.gocapable.com/diagrams/container-diagram.html)

[C4 modelBack to the C4 overview.](https://help.gocapable.com/diagrams/c4-model.html)

---

_Context first. Always._