Bazel 会根据源代码构建软件，这些源代码以目录树（称为工作区）的形式组织在一起。工作区中的源文件按软件包嵌套层次结构进行组织，其中每个软件包都是一个目录，其中包含一组相关源文件和一个 BUILD 文件。BUILD 文件指定可以从源构建哪些软件输出。
Workspace
工作区是文件系统上的一种目录树，其中包含要构建的软件的源文件。每个工作区都有一个名为 WORKSPACE 的文本文件，该文件可以为空，也可以包含对构建输出所需的外部依赖项的引用。
包含名为 WORKSPACE 的文件的目录被视为工作区的根目录。因此，Bazel 会忽略以包含 WORKSPACE 文件的子目录为根目录的工作区中的任何目录树，因为它们构成另一个工作区。
Bazel 还支持将 WORKSPACE.bazel 文件用作 WORKSPACE 文件的别名。如果这两个文件都存在，则系统会使用 WORKSPACE.bazel。
仓库
代码会整理到代码库中。包含 WORKSPACE 文件的目录是主代码库的根目录，也称为 @。其他（外部）代码库在 WORKSPACE 文件中使用工作区规则进行定义。
如需了解与 Bazel 捆绑在一起的工作区规则，请参阅 Build Encyclopedia 中的工作区规则部分以及关于嵌入式 Starlark 代码库规则的文档。
由于外部代码库本身就是代码库，因此它们通常也包含 WORKSPACE 文件。不过，Bazel 会忽略这些额外的 WORKSPACE 文件。特别是，以传递方式依赖的代码库不会自动添加。
软件包
代码库中的代码组织主要单元是软件包。软件包是相关文件的集合，以及关于如何使用这些文件生成输出工件的规范。
软件包指的是包含名为 BUILD（或 BUILD.bazel）的文件的目录。软件包包含其目录中的所有文件，以及其下的所有文件，但那些本身包含 BUILD 文件的子目录除外。根据此定义，任何文件或目录都不能属于两个不同的软件包。
例如，以下目录树中有两个软件包：my/app 和子软件包 my/app/tests。
请注意，my/app/data 不是软件包，而是属于软件包 my/app 的目录。
src/my/app/BUILD
src/my/app/app.cc
src/my/app/data/input.txt
src/my/app/tests/BUILD
src/my/app/tests/test.cc
目标
软件包是包含目标的容器，目标在软件包的 BUILD 文件中定义。大多数目标都是两种主要种类之一，即文件和规则。
文件进一步分为两种。源文件通常由人们编写并签入代码库。生成的文件（有时称为衍生文件或输出文件）不会签入，而是从源文件生成。
第二种定位条件是使用规则声明的。每个规则实例都指定了一组输入和一组输出文件之间的关系。规则的输入可以是源文件，但也可以是其他规则的输出。
在大多数情况下，规则的输入是源文件还是生成的文件并不重要；重要的只是该文件的内容。这使得将复杂的源文件替换为由规则生成的生成的文件，例如，手动维护高度结构化文件的负担过于繁琐时，会有人编写程序来派生该文件。该文件的使用者无需做出任何更改。相反，生成的文件可能很容易被只在本地更改的源文件替换。
规则的输入内容可能还包括其他规则。此类关系的确切含义通常非常复杂且取决于语言或规则，但直观上讲也很简单：对于一个输入，C++ 库规则 A 可能有另一个 C++ 库规则 B。此依赖项的影响在于，B 的头文件在编译期间可供 A 使用，B 的符号在链接期间可供 A 使用，B 的运行时数据在执行期间可供 A 使用。
所有规则的不变之处在于，由规则生成的文件始终与规则本身属于同一软件包；无法将文件生成到其他软件包中。不过，规则的输入来自其他软件包的情况并不少见。
软件包组是一组软件包，其用途是限制某些规则的可访问性。软件包组由 package_group 函数定义。它们具有三个属性：它们包含的软件包列表、其名称及其包含的其他软件包组。引用它们的唯一方式是：通过规则的 visibility 属性或 package 函数的 default_visibility 属性来引用它们；它们不会生成或使用文件。如需了解详情，请参阅 package_group 文档。