A component diagram shows a system as a set of replaceable building blocks and the interfaces they offer to and need from each other. Architects use it to agree on boundaries and contracts; developers use it to see what they may swap without breaking callers.
A component is a modular, replaceable part with a well-defined contract: a service, a library, a microservice, a plug-in. The contract has two sides. A provided interface is what the component offers (its API). A required interface is what it needs from somewhere else to work. Wiring a required interface to a matching provided one is called an assembly.
The diagram deliberately ignores how each component is built inside. It answers: what are the big pieces, what does each promise, and what does each depend on? That makes it the natural diagram for microservice boundaries, plug-in architectures and anything you plan to replace later.
A component is a rectangle with the small two-pronged icon (or the «component» keyword). The lollipop (line ending in a circle) is a provided interface; the socket (half circle) is a required one. When a ball sits in a socket, the two components are connected. A port is a small square on the boundary: a named doorway grouping related interfaces, useful when one component exposes several distinct channels. A plain dashed arrow is a looser dependency.
Walkthrough: the storefront requires two interfaces, ICatalog and ICheckout, provided by the Catalog and Checkout components. Checkout in turn requires IStock from Inventory and IPayment from the Payment Adapter. Because Checkout only knows the IPayment contract, swapping Stripe for another provider means writing a new adapter that provides the same interface; nothing else on the diagram changes.
Walkthrough: an AI retrieval service exposes one api port to the chat frontend and three outbound ports: embed, search and generate. Each port connects to an external component: an embedding model, a vector store, an LLM provider. Drawing it this way documents exactly which seams exist for swapping a model or a database, and gives testers obvious places to plug in fakes.
Read a component diagram from the consumer side: start at the component a user touches, follow each socket to the lollipop that satisfies it, and keep going until you reach components with no required interfaces. Any socket left unconnected is a dependency the deployment must still provide, which is often the most useful finding of the whole exercise.
Common mistakes: drawing every class as a component (components should be units you could build, deploy or replace on their own); naming interfaces after the implementation (StripeAPI instead of IPayment), which defeats the purpose of the contract; and mixing in servers and containers, which belong on a deployment diagram. Keep one diagram per level of zoom, in the spirit of the C4 model: a system view, then one component view per container.
PlantUML supports components, interfaces and the ball-and-socket links (-() and )-):
@startuml
component Storefront
component Catalog
component Checkout
component Inventory
component "Payment Adapter" as Pay
interface ICatalog
interface ICheckout
interface IStock
interface IPayment
Catalog - ICatalog
Checkout - ICheckout
Inventory - IStock
Pay - IPayment
Storefront ..> ICatalog
Storefront ..> ICheckout
Checkout ..> IStock
Checkout ..> IPayment
@endumlMermaid has no component diagram; C4 component views (Structurizr or Mermaid's experimental C4 support) are the common alternative.