Angular 以类似于 ES 模块的方式引入了模块封装的概念。 它基本上意味着可声明的类型——组件、指令和管道——只能由在该模块内声明的组件使用。 例如，如果我尝试使用下面的代码在 App 模块的 App 组件内使用 A 模块中的 a-comp：

@Component({
  selector: 'my-app',
  template: `
      <h1>Hello {{name}}</h1>
      <a-comp></a-comp>
  `
})
export class AppComponent { }

会收到这个错误消息：

Template parse errors: ‘a-comp’ is not a known element

这是因为 App 模块中没有声明 a-comp。 如果我想使用这个组件，我需要导入定义这个组件的模块。解决方案如下：

@NgModule({
  imports: [..., AModule]
})
export class AppModule { }

这就是封装发挥作用的地方：A 模块必须通过将 a-comp 添加到 exports 数组来将其声明为在其他 module 内可用：

@NgModule({
  ...
  declarations: [AComponent],
  exports: [AComponent]
})
export class AModule { }

大多数 Angular 新手认为 Providers 也有封装，这种想法是错误的。可以在应用程序内的任何位置访问在任何非延迟加载模块中声明的 Providers.

Modules hierarchy

关于 imported modules 的最大困惑是开发人员认为这些被导入的 Modules 在应用运行时维护了一种层次结构，并且假设导入其他模块的模块成为被导入模块的父模块。

然而，事实并非如此。所有模块在编译阶段合并。因此，导入的模块和导入的模块之间没有层次关系。

所需命名空间之一被定义为默认命名空间。 此命名空间的控制标记不需要前缀。

<View> 标签是必需的，在上面的示例中，核心命名空间在第一行定义。 当然开发人员可以定义任何名称。 例如，为了使标签名称更短，还可以使用 c 而不是 core.