Component

For the most part, dependency-management-data focusses on the Repo Key as the primary identifier and interface for how dependencies are grouped together.

However, there are some cases where you may have a dependency dump that doesn't fit into the Repo Key model, for instance if you have a monorepo with multiple individual services within it, or if you use a tool to produce a dependency scan (i.e. a Software Bill of Materials) which doesn't encode the source repository information.

In these cases, we want to be able to have some unique identifier which may not be directly linked to a repository, but which should be still explanatory.

This then leads us to a separate definition of how dependencies may be used by software by describing them in terms of the "Component" that uses the dependencies.

Your own service catalog and internal tooling may have a definition, but a good example is Backstage's definition of a Component is:

A Component describes a software component. It is typically intimately linked to the source code that constitutes the component, and should be what a developer may regard a "unit of software", usually with a distinct deployable or linkable artifact.