What makes separate parts composable?

A view can consume a resource supplied elsewhere; several views can use the same operational object. The composition boundary is useful when participants agree on meaning, effects and access.

A uniform namespace helps connect those parts. It does not by itself solve conflicting updates, stale data, version changes or authorization. These are design obligations at the boundaries.

A good stability question is concrete: if we replace the model, provider or renderer, which consumers must change, and why? The answer can guide both implementation and evaluation.

One report, two consumers

Suppose a report page reads the illustrative resource /reports/weekly, and a summarization tool reads the same resource. The page need not know how the tool organizes its prompt. The tool need not know how many columns the page uses. Both rely on what reading that address returns.

To add “submit for review,” the page can connect an action provided by the application. The composition now includes the report resource, submission action and authority to invoke it—not just a title, body and button. Arranging those visual elements establishes a presentation; connecting them to the same report and its supported effects establishes this business composition.

This is the value of the boundary: the page, tool and resource implementation can change separately while retaining the agreements they share.