Component

Understand This First

• Abstraction – 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. The term operates at the architectural scale. Components are the nouns in the sentence that describes your system’s architecture.

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, 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 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 (its internals belong together) and communicates with other components through narrow, well-defined channels (low coupling). 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 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, 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.

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 between components. Every interface is a contract 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.

Related Patterns

• Uses: Interface, Boundary — every component has both.
• Refined by: Module — a module is a component at a finer grain.
• Measured by: Cohesion, Coupling — the quality metrics for component design.
• Produced by: Decomposition — components are what you get when you decompose a system.
• Depends on: Abstraction — a component hides its internals behind an abstraction.