Component Architecture¶
What a component is¶
In this venture, a component is a specified, potentially reusable building block that a product may adopt — for example, a KPI dashboard pattern, a validated input pattern, a configuration block pattern, or a print-ready report layout. Components are documented in ../../components/component-catalog.md, which is maintained separately from this venture's docs tree.
Components are specified before they're claimed as reusable¶
A pattern only becomes a "component" once it has been deliberately specified — documented with its purpose, interface (what inputs/configuration it needs), and usage guidance — in the component catalog. A pattern used once inside a single product is just part of that product; it is not yet a component. It becomes a candidate component only when:
- It has proven useful in at least one product, and
- A deliberate decision is made to generalize and document it for reuse, rather than letting a second product silently copy the first product's implementation.
Until that happens, no pattern should be referred to as "the standard component for X" — that claim requires the catalog entry to actually exist.
How a product adopts a component¶
A product's specification (products/<slug>/) should explicitly state which cataloged
components it uses and how, rather than silently reimplementing a component's logic
without reference to the catalog. This keeps the relationship between products and
components traceable: if a component's specification changes, it's possible to find
every product that depends on it.
Reuse without forcing uniformity¶
Consistent with ../strategy/product-philosophy.md, adopting a component is a judgment call, not an obligation. A product with needs that don't fit an existing component should implement something product-specific rather than distorting a component to fit. If that product-specific solution later proves broadly useful, it can be proposed into the catalog at that point.
Ownership note¶
The component catalog itself
(ventures/digital-products/components/) is maintained by a separate work stream from
this docs/ tree. This document describes how products relate architecturally to
components; it does not define the catalog's own structure or content.