catalog model: introduce the System, Domain, and Resource kinds

Feature Suggestion

Before removing the alpha label on the catalog, I think it would be sensible to have at least the System and Domain kinds in place, and preferably also an outline of Resource, as defined in the system model RFC.

Possible Implementation

I would argue that there is value in adding these in a very barebones manner, and iterate. What we need is:

• The skeleton of the kinds themselves
• Adding system and domain fields in the relevant specs of various kinds where appropriate, such as Component
• Defining the relations that the system and domain fields translate to, probably new ones along the lines of partOf, since the existing ones don’t seem like a great match.

Context

See the following RFCs:

• Backstage System Model
• On specific semantic of systems, components, and resources in Catalog

[tragiclifestories]

I think we’ve moved beyond the point that this discussion is directly related to this issue so I’ve raised https://github.com/backstage/backstage/issues/3815 as a strawman proposal specifically focused on modelling monolithic apps.

[freben]

@mbruggmann Right.

does that risk weakening the Component concept? See the discussion above of a website starting its life as a component and ending up as an application when it grows. This changes its kind/namespace/name identifier, and hence urls and references everywhere.

Or do we dive head first into applications and choose to always model websites, services and client apps as applications from the get-go? If we do, and that’s OK if we do, I think we need to clearly adjust messaging and docs etc.