系统模型

我们相信，围绕软件和资源的强有力的共同理解和术语会带来更好的Backstage体验。

本说明源自本 RFC。请注意，Backstage 尚未支持其中的某些概念。

核心实体

我们在 Backstage 目录中使用这三个核心实体对软件进行建模(下文将进一步解释)：

组件 是单个软件 API 是不同组件之间的界限 资源 是运行组件所需的物理或虚拟基础设施

组件

组件是一个软件，例如移动功能、网站、后端服务或数据管道(列表并不详尽)。 组件可以在源控制中跟踪，也可以使用一些现有的开源或商业软件。

反过来，组件也可能使用其他组件实现的 API，或直接依赖于运行时附加给它的组件或资源。

API

应用程序接口构成了一个重要(也许是最重要)的抽象概念，使大型软件生态系统得以扩展。 因此，应用程序接口是Backstage模型中的一等公民，也是发现生态系统中现有功能的主要途径。

API 由组件实现，并在组件之间形成边界。 它们可以使用 RPC IDL(如 Protobuf、GraphQL......)、数据模式(如 Avro、TFRecord......)或代码接口定义。 在任何情况下，组件暴露的 API 都需要采用已知的机器可读格式，这样我们才能在其基础上构建进一步的工具和分析。

应用程序接口(API)具有可见性：它们要么是公开的(任何其他组件都可以使用它们)，要么是受限的(仅对允许列表中的一组消费者可用)，要么是私有的(仅在其系统内可用)。 由于公开的应用程序接口(API)将成为组件间交互的主要方式，因此 Backstage 支持对所有应用程序接口(API)进行文档化、索引化和搜索，以便我们作为开发人员可以浏览它们。

资源

资源是组件在运行时所需的基础设施，如 BigTable 数据库、Pub/Sub 主题、S3 buckets 或 CDN。 将它们与组件和系统一起建模，可以更好地可视化资源占用情况，并围绕它们创建工具。

组织实体

用户

用户指的是一个人，如雇员、承包商或类似人员。

组

小组指的是一个组织实体，例如一个团队、一个业务单位或一个兴趣小组中松散的人员集合。

生态系统建模

大量组件、应用程序接口和资源的目录可能非常细化，难以作为一个整体来理解。 因此，使用以下(可选)概念对这些实体进行进一步分类可能会比较方便：

系统 是实体的集合，它们相互合作以执行某些功能 域将实体和系统与业务的一部分联系起来

系统

随着软件的复杂性不断增加，系统成为帮助我们推理软件生态系统的一个重要抽象层。 系统是一个有用的概念，因为它允许我们忽略消费者对某一功能的实现细节，同时允许拥有团队在他们认为合适的时候进行更改(导致低耦合)。

从这个意义上说，系统是资源和组件的集合，公开一个或多个公共应用程序接口。 系统建模的主要好处是，它为任何消费者隐藏了资源和组件之间的私有应用程序接口。 这意味着，作为 Owners，您可以在组件和资源方面不断演进实现，而消费者却无法察觉。 通常情况下，系统最多由几个组件组成(系统分组见 "领域")。

例如，播放列表管理系统可以封装更新播放列表的后端服务、查询播放列表的后端服务和存储播放列表的数据库。 它可以公开 RPC API、每日快照数据集和播放列表更新的事件流。

域名

虽然系统是相关实体的基本封装级别，但将共享术语、领域模型、衡量标准、关键绩效指标、业务目的或文档的系统集合在一起，即形成一个有边界的上下文，通常是非常有用的。

例如，如果 "支付 "域中的不同系统都能提供一些文档，说明如何接受新产品或使用案例的支付，在其应用程序接口中共享相同的实体类型，并能很好地相互集成，那就很有意义了。 其他域可以是 "内容摄取"、"广告 "或 "搜索"。

其他

位置

位置是一个标记，用于引用其他可查找目录数据的地方。

类型

系统中的类型字段没有固定的含义，用户可自行分配类型并按需使用，例如用于链接验证或创建自定义用户界面组件。 一些常见的预定义类型如图所示。生态系统模型图.

模板

模板定义既描述了在脚手架向导前端部分呈现的参数，也描述了在脚手架化该组件时执行的步骤。