MODULE 07 · SYSTEM ARCHITECTURE

Component

A distinct part of a system with a clear responsibility, boundary, interface, and dependencies.

What is it?

A component is a distinct part of a system with a clear responsibility, boundary, interface, and dependencies.

A component owns one meaningful area of work. Its boundary makes it easier to see what belongs inside, what other parts are allowed to ask for, and what the component needs from the rest of the system.

Responsibility

The work this part is accountable for.

Boundary

The line separating its work from other parts.

Interface

The requests, inputs, outputs, or events it exposes.

Dependencies

The data, services, or tools it needs to do its job.

Think of it like...

Think of a component as a specialist team inside a company.

The team has a clear job, a way for other teams to make requests, and a list of information or support it needs. Other teams do not need to know every internal step.

Request

Component Boundary

Internal Work

Result

What does it do?

A component turns a large system into parts that people can understand, build, test, operate, and change.

Own a capability

Keep related rules and behavior together.

Protect decisions

Prevent every caller from depending on internal details.

Define collaboration

Make inputs, outputs, and failure behavior visible.

Limit change impact

Allow internal changes without rewriting the whole system.

Trade-off: more boundaries can improve ownership and change safety, but each boundary also adds coordination, contracts, testing, and possible failure points.

Where is it used?

Components appear at several levels. A component can be a module inside one application, a service in a distributed system, or a user-interface area with a reusable contract.

Checkout

Own cart validation, totals, and order creation.

Authentication

Own identity checks, sessions, and access decisions.

Notification

Choose a channel and deliver product messages.

Search

Turn a query into a ranked set of results.

Payment

Coordinate authorization and provider responses.

User interface

Package a repeatable interaction such as a date picker or checkout form.

Example

An online store's Checkout Component

When a shopper selects “Place order,” the checkout component coordinates several decisions. The page does not need to know how stock is reserved or how payment is authorized; it asks the component through its interface.

What belongs inside

Validate the cart and shipping details.
Ask inventory whether items can be reserved.
Request payment authorization.
Create the order and return its status.

What the interface promises

placeOrder(cart, payment) returns a clear outcome such as confirmed, payment_failed, or out_of_stock.

The component can change its internal sequence later without changing every caller.

Customer

Checkout Page

Checkout Component

Order Result

How it connects

Components connect through explicit interfaces and dependencies. The dependency direction should be understandable: the component asks for what it needs, while callers depend on the component's public contract.

Client

Component Interface

Component Logic

Data / Service Dependency

Stable interface

Callers can keep working while implementation details change.

Visible dependency

Teams can plan for latency, permissions, availability, and ownership.

Testable boundary

Inputs and outputs make focused tests and failure scenarios easier to define.

Do Not Confuse

Component vs service

A service is a component that provides a capability through an interface. A component does not have to run as a separate service or process.

Component vs module

A module is usually a code organization unit. A component is a responsibility and boundary; one component may contain several modules.

Component vs API

An API is the communication contract. A component is the part that owns the responsibility behind that contract.

Component vs feature

A feature is a user or business capability. A feature may cross several components, while a component is one bounded system part.

Component vs microservice

A microservice is an independently deployable service. A component can live inside a monolith and still have a strong boundary.

Component vs database table

A table stores data. A component owns behavior and decisions, and may use several tables or other data sources.

Topic Glossary

ENGLISH TERM	中文	SIMPLE ENGLISH	中文小白理解
Component	组件	A distinct part of a system with a clear responsibility.	系统中负责一件明确工作的独立部分。
Responsibility	职责	The work a component owns.	一个组件负责完成的工作。
Boundary	边界	The line separating one responsibility from another.	把不同职责分开的界线。
Interface	接口	The way other parts ask a component to do work.	其他部分请求组件工作的方式。
Dependency	依赖	A thing a component needs in order to work.	组件正常工作所需要的其他东西。
Contract	契约	The agreed inputs, outputs, and behavior between parts.	各部分约定好的输入、输出和行为。
Module	模块	A code organization unit that groups related implementation.	把相关代码组织在一起的单元。
Service	服务	A component that provides a capability through an interface.	通过接口提供某项能力的组件。
Monolith	单体应用	An application deployed as one main unit.	作为一个主要单元部署的应用。
Microservice	微服务	An independently deployable service.	可以独立部署的服务。
Coupling	耦合	How strongly one part depends on another part's details.	一个部分对另一个部分内部细节的依赖程度。

What to Remember

A component is a system part with a clear job and a deliberate boundary.

The boundary is valuable when it makes ownership, communication, testing, and change impact easier to manage.

PM Perspective: Ask what responsibility the component owns, who uses its interface, what dependencies it needs, what happens when a dependency fails, and whether the boundary is worth the operating and coordination cost.

Responsibility

Boundary

Interface

Useful Component