---
slug: component
type: pattern
summary: "A bounded piece of a larger system with a defined role and an explicit interface, the noun in the sentence that describes your architecture."
created: 2026-04-04
updated: 2026-04-05
related:
  abstraction:
    relation: depends-on
    note: "A component hides its internals behind an abstraction."
  architecture:
    relation: scoped-by
    note: "Architecture decisions determine what the major components are."
  boundary:
    relation: uses
    note: "Every component has both."
  cohesion:
    relation: measured-by
    note: "The quality metrics for component design."
  composition:
    relation: assembled-via
    note: "Components are the building blocks that composition assembles."
  coupling:
    relation: measured-by
    note: "The quality metrics for component design."
  decomposition:
    relation: produced-by
    note: "Components are what you get when you decompose a system."
  interface:
    relation: uses
    note: "Every component has both."
  module:
    relation: refined-by
    note: "A module is a component at a finer grain."
  separation-of-concerns:
    relation: embodies
    note: "Each component should own a distinct concern."
  task-decomposition:
    relation: assigned-via
    note: "Agents are often assigned work at component granularity."
---
# Component

> **Pattern**
>
> A named solution to a recurring problem.

## Understand This First

- [Abstraction](abstraction.md) -- a component hides its internals behind an abstraction.

## Context

Systems aren't built as single, undifferentiated masses. They're assembled from parts. A **component** is one of those parts: a bounded piece of a larger system with a defined role and an explicit [interface](interface.md). The term operates at the **architectural** scale. Components are the nouns in the sentence that describes your system's [architecture](architecture.md).

A component might be a microservice, a UI widget, a library, a database, or an agent tool. What makes it a component isn't its size but the fact that it has a clear purpose, a defined [boundary](boundary.md), and a way for other parts of the system to interact with it.

## Problem

How do you organize a system so that its parts can be understood, built, and changed independently?

## Forces

- A system that is one big piece is hard to understand and hard to change.
- Splitting into too many tiny pieces creates coordination overhead.
- Each component needs a clear role — vague or overlapping responsibilities lead to confusion.
- Components must communicate, and every point of communication is a potential source of failure.

## Solution

Identify the natural groupings in your system — clusters of behavior that change together and serve a common purpose. Give each grouping a name, a clear responsibility, and an [interface](interface.md) that other components can use. The interface is the component's public face; everything behind it is an implementation detail.

A well-designed component has high [cohesion](cohesion.md) (its internals belong together) and communicates with other components through narrow, well-defined channels (low [coupling](coupling.md)). You should be able to describe what a component does in a sentence or two. If the description requires "and" three times, the component is probably doing too much.

In agentic workflows, components serve as natural work units. You can ask an agent to "implement the authentication component" or "add error handling to the notification component." The component boundary tells the agent what is in scope and what is not.

## How It Plays Out

A web application is divided into components: an authentication service, a content management module, a search engine, and a notification system. Each has its own codebase, its own tests, and its own deployment pipeline. When the search engine needs to be replaced, the team swaps it out without touching the other components because the [contract](contract.md) at the interface remains the same.

An AI agent working on a large project is told: "The logging component needs to support structured output." The agent reads the component's interface, understands its [dependencies](dependency.md), makes the change, and runs the component's tests. It doesn't need to understand the rest of the system. The component boundary limited the blast radius of the change.

> **💡 Example Prompt**
>
> "The logging component needs to support structured JSON output. Read the component's interface, make the change, and run the component's tests. Don't modify code outside the logging directory."

## Consequences

Thinking in components gives a system structure that scales with complexity. Teams can own components. Agents can work within component boundaries. Testing can target individual components in isolation.

The cost is the overhead of defining and maintaining [interfaces](interface.md) between components. Every interface is a [contract](contract.md) that must be honored as both sides evolve. Over time, component boundaries may drift from the actual structure of the problem. What made sense at the start may not make sense after a year of growth. Review component boundaries periodically.

---

- [Next: Module](module.md)
- [Previous: Abstraction](abstraction.md)