diff --git a/aio/content/guide/architecture-components.md b/aio/content/guide/architecture-components.md
new file mode 100644
index 00000000000..6e1bfced2c1
--- /dev/null
+++ b/aio/content/guide/architecture-components.md
@@ -0,0 +1,169 @@
+# Introduction to components
+
+
+
+A _component_ controls a patch of screen called a *view*. For example, individual components define and control each of the following views from the Tutorial:
+
+* The app root with the navigation links.
+* The list of heroes.
+* The hero editor.
+
+You define a component's application logic—what it does to support the view—inside a class. The class interacts with the view through an API of properties and methods.
+
+For example, the `HeroListComponent` has a `heroes` property that returns an array of heroes that it acquires from a service. `HeroListComponent` also has a `selectHero()` method that sets a `selectedHero` property when the user clicks to choose a hero from that list.
+
+
+
+The `@Component` decorator identifies the class immediately below it as a component class, and specifies its metadata. In the example code below, you can see that `HeroListComponent` is just a class, with no special Angular notation or syntax at all. It's not a component until mark it as one with the `@Component` decorator.
+
+The metadata for a component tells Angular where to get the major building blocks it needs to create and present the component and its view. In particular, it associates a _template_ with the component, either directly with inline code, or by reference. Together, the component and its template describe a _view_.
+
+In addition to containing or pointing to the template, the `@Component` metadata configures, for example, how the component can be referenced in HTML and what services it requires.
+
+ Here's an example of basic metadata for `HeroListComponent`:
+
+
+
+You define a component's view with its companion template. A template is a form of HTML that tells Angular how to render the component.
+
+Components and their associated views are typically arranged hierarchically, allowing you to modify or show and hide entire UI sections or pages as a unit. The template immediately associated with a component defines that component's _host view_. The template can also define a _view hierarchy_, which can contain _embedded views_, as well as views hosted by other components.
+
+
+`, and also includes Angular template-syntax elements, `*ngFor`, `{{hero.name}}`, `(click)`, `[hero]`, and ` `, it also has some differences. Code like `*ngFor`, `{{hero.name}}`, `(click)`, `[hero]`, and `
+
+
+
+
+### Directives
+
+
+
+Angular templates are *dynamic*. When Angular renders them, it transforms the DOM according to the instructions given by *directives*. A directive is a class with a `@Directive` decorator.
+
+A component is technically a directive - but components are so distinctive and central to Angular applications that Angular defines the `@Component` decorator, which extends the `@Directive` decorator with template-oriented features.
+
+There are two kinds of directives besides components: _structural_ and _attribute_ directives. Just as for components, the metadata for a directive associates the class with a `selector` that you use to insert it into HTML. In templates, directives typically appear within an element tag as attributes, either by name or as the target of an assignment or a binding.
+
+#### Structural directives
+
+Structural directives alter layout by adding, removing, and replacing elements in DOM. The example template uses two built-in structural directives to add application logic to how the view is rendered:
+
+
+
+Angular apps are modular and Angular has its own modularity system called _NgModules_. An NgModule is a container for a cohesive block of code dedicated to an application domain, a workflow, or a closely related set of capabilities. It can contain components, service providers, and other code files whose scope is defined by the containing NgModule. It can import functionality that is exported from other NgModules, and export selected functionality for use by other NgModules.
+
+Every Angular app has at least one NgModule class, [the _root module_](guide/bootstrapping), which is conventionally named `AppModule` and resides in a file named `app.module.ts`. You launch your app by *bootstrapping* the root NgModule.
+
+While a small application might have only one NgModule, most apps have many more _feature modules_. The _root_ NgModule for an app is so named because it can include child NgModules in a hierarchy of any depth.
+
+## NgModule metadata
+
+An NgModule is defined as a class decorated with `@NgModule`. The `@NgModule` decorator is a function that takes a single metadata object, whose properties describe the module. The most important properties are as follows.
+
+* `declarations`—The [components](guide/architecture-components), _directives_, and _pipes_ that belong to this NgModule.
+
+* `exports`—The subset of declarations that should be visible and usable in the _component templates_ of other NgModules.
+
+* `imports`—Other modules whose exported classes are needed by component templates declared in _this_ NgModule.
+
+* `providers`—Creators of [services](guide/architecture-services) that this NgModule contributes to the global collection of services; they become accessible in all parts of the app.
+
+* `bootstrap`—The main application view, called the _root component_, which hosts all other app views. Only the _root NgModule_ should set this `bootstrap` property.
+
+Here's a simple root NgModule definition:
+
+
+
+
+
+A component and its template together define a _view_. A component can contain a _view hierarchy_, which allows you to define arbitrarily complex areas of the screen that can be created, modified, and destroyed as a unit. A view hierarchy can mix views defined in components that belong to different NgModules. This is often the case, especially for UI libraries.
+
+
+
+
+
+When you create a component, it is associated directly with a single view, called the _host view_. The host view can be the root of a view hierarchy, which can contain _embedded views_, which are in turn the host views of other components. Those components can be in the same NgModule, or can be imported from other NgModules. Views in the tree can be nested to any depth.
+
+
+
+Angular ships as a collection of JavaScript modules. You can think of them as library modules. Each Angular library name begins with the `@angular` prefix. Install them with the `npm` package manager and import parts of them with JavaScript `import` statements.
+
+
+
+For example, import Angular's `Component` decorator from the `@angular/core` library like this:
+
+
diff --git a/aio/content/guide/architecture-next-steps.md b/aio/content/guide/architecture-next-steps.md
new file mode 100644
index 00000000000..713d206c68e
--- /dev/null
+++ b/aio/content/guide/architecture-next-steps.md
@@ -0,0 +1,48 @@
+# Next steps: tools and techniques
+
+Once you have understood the basic building blocks, you can begin to learn more about the features and tools that are available to help you develop and deliver Angular applications. Angular provides a lot more features and services that are covered in this documentation.
+
+#### Responsive programming tools
+
+ * [Lifecycle hooks](guide/lifecycle-hooks): Tap into key moments in the lifetime of a component, from its creation to its destruction, by implementing the lifecycle hook interfaces.
+
+ * [Observables and event processing](guide/observables): How to use observables with components and services to publish and subscribe to messages of any type, such as user-interaction events and asynchronous operation results.
+
+#### Client-server interaction tools
+
+ * [HTTP](guide/http): Communicate with a server to get data, save data, and invoke server-side actions with an HTTP client.
+
+ * [Server-side Rendering](guide/universal): Angular Universal generates static application pages on the server through server-side rendering (SSR). This allows you to run your Angular app on the server in order to improve performance and show the first page quickly on mobile and low-powered devices, and also facilitate web crawlers.
+
+ * [Service Workers](guide/service-worker-intro): A service worker is a script that runs in the web browser and manages caching for an application. Service workers function as a network proxy. They intercept outgoing HTTP requests and can, for example, deliver a cached response if one is available. You can significantly improve the user experience by using a service worker to reduce dependency on the network.
+
+#### Domain-specific libraries
+
+ * [Animations](guide/animations): Animate component behavior
+without deep knowledge of animation techniques or CSS with Angular's animation library.
+
+ * [Forms](guide/forms): Support complex data entry scenarios with HTML-based validation and dirty checking.
+
+#### Support for the development cycle
+
+ * [Testing Platform](guide/testing): Run unit tests on your application parts as they interact with the Angular framework.
+
+ * [Internationalization](guide/i18n): Angular's internationalization (i18n) tools can help you make your app available in multiple languages.
+
+ * [Compilation](guide/aot-compiler): Angular provides just-in-time (JIT) compilation for the development environment, and ahead-of-time (AOT) compilation for the production environment.
+
+ * [Security guidelines](guide/security): Learn about Angular's built-in protections against common web-app vulnerabilities and attacks such as cross-site scripting attacks.
+
+#### Setup and deployment tools
+
+ * [Setup for local development](guide/setup): Learn how to set up a new project for development with QuickStart.
+
+ * [Installation](guide/npm-packages): The [Angular CLI](https://cli.angular.io/), Angular applications, and Angular itself depend on features and functionality provided by libraries that are available as [npm](https://docs.npmjs.com/) packages.
+
+ * [Typescript Configuration](guide/typescript-configuration): TypeScript is the primary language for Angular application development.
+
+ * [Browser support](guide/browser-support): Learn how to make your apps compatible across a wide range of browsers.
+
+ * [Deployment](guide/deployment): Learn techniques for deploying your Angular application to a remote server.
+
+
diff --git a/aio/content/guide/architecture-services.md b/aio/content/guide/architecture-services.md
new file mode 100644
index 00000000000..ccbed6c4ea3
--- /dev/null
+++ b/aio/content/guide/architecture-services.md
@@ -0,0 +1,73 @@
+# Introduction to services and dependency injection
+
+
+
+_Service_ is a broad category encompassing any value, function, or feature that an app needs. A service is typically a class with a narrow, well-defined purpose. It should do something specific and do it well.
+
+
+Angular distinguishes components from services in order to increase modularity and reusability.
+
+* By separating a component's view-related functionality from other kinds of processing, you can make your component classes lean and efficient. Ideally, a component's job is to enable the user experience and nothing more. It should present properties and methods for data binding, in order to mediate between the view (rendered by the template) and the application logic (which often includes some notion of a _model_).
+
+* A component should not need to define things like how to fetch data from the server, validate user input, or log directly to the console. Instead, it can delegate such tasks to services. By defining that kind of processing task in an injectable service class, you make it available to any component. You can also make your app more adaptable by injecting different providers of the same kind of service, as appropriate in different circumstances.
+
+Angular doesn't *enforce* these principles. Angular does help you *follow* these principles by making it easy to factor your
+application logic into services and make those services available to components through *dependency injection*.
+
+## Service examples
+
+Here's an example of a service class that logs to the browser console:
+
+
+
+## Dependency injection
+
+
+
+Components consume services; that is, you can *inject* a service into a component, giving the component access to that service class. To define a class as a service in Angular, use the `@Injectable` decorator to provide the metadata that allows Angular to inject it into a component as a *dependency*. Most dependencies are services.
+
+*Dependency injection* (often called DI) is wired into the Angular framework and used everywhere to provide new components with the services they need.
+
+* The *injector* is the main mechanism. You don't have to create an Angular injector. Angular creates an application-wide injector for you during the bootstrap process.
+
+* The injector maintains a *container* of service instances that it has already created, and reuses them if possible.
+
+* A *provider* is a recipe for creating a service -- typically the service class itself. For any service you need in your app, you must register a provider with the app's injector, so that the injector can use it to create new service instances.
+
+When Angular creates a new instance of a component class, it determines which services that component needs by looking at the types of its constructor parameters. For example, the constructor of `HeroListComponent` needs a `HeroService`:
+
+
+
diff --git a/aio/content/guide/architecture.md b/aio/content/guide/architecture.md
index 0203cb29020..e1d37bff6cd 100644
--- a/aio/content/guide/architecture.md
+++ b/aio/content/guide/architecture.md
@@ -1,533 +1,137 @@
-# Architecture Overview
+# Architecture overview
-Angular is a framework for building client applications in HTML and
-either JavaScript or a language like TypeScript that compiles to JavaScript.
+Angular is a platform and framework for building client applications in HTML and TypeScript.
+Angular is itself written in TypeScript. It implements core and optional functionality as a set of TypeScript libraries that you import into your apps.
-The framework consists of several libraries, some of them core and some optional.
+The basic building blocks of an Angular application are _NgModules_, which provide a compilation context for _components_. NgModules collect related code into functional sets; an Angular app is defined by a set of NgModules. An app always has at least a _root module_ that enables bootstrapping, and typically has many more _feature modules_.
-You write Angular applications by composing HTML *templates* with Angularized markup,
-writing *component* classes to manage those templates, adding application logic in *services*,
-and boxing components and services in *modules*.
+* Components define *views*, which are sets of screen elements that Angular can choose among and modify according to your program logic and data. Every app has at least a root component.
-Then you launch the app by *bootstrapping* the _root module_.
-Angular takes over, presenting your application content in a browser and
-responding to user interactions according to the instructions you've provided.
+* Components use *services*, which provide specific functionality not directly related to views. Service providers can be *injected* into components as *dependencies*, making your code modular, reusable, and efficient.
-Of course, there is more to it than this.
-You'll learn the details in the pages that follow. For now, focus on the big picture.
+Both components and services are simply classes, with *decorators* that mark their type and provide metadata that tells Angular how to use them.
+
+* The metadata for a component class associates it with a *template* that defines a view. A template combines ordinary HTML with Angular *directives* and *binding markup* that allow Angular to modify the HTML before rendering it for display.
+
+* The metadata for a service class provides the information Angular needs to make it available to components through *Dependency Injection (DI)*.
+
+An app's components typically define many views, arranged hierarchically. Angular provides the `Router` service to help you define navigation paths among views. The router provides sophisticated in-browser navigational capabilities.
+
+## Modules
+
+Angular defines the `NgModule`, which differs from and complements the JavaScript (ES2015) module. An NgModule declares a compilation context for a set of components that is dedicated to an application domain, a workflow, or a closely related set of capabilities. An NgModule can associate its components with related code, such as services, to form functional units.
+
+Every Angular app has a _root module_, conventionally named `AppModule`, which provides the bootstrap mechanism that launches the application. An app typically contains many functional modules.
+
+Like JavaScript modules, NgModules can import functionality from other NgModules, and allow their own functionality to be exported and used by other NgModules. For example, to use the router service in your app, you import the `Router` NgModule.
+
+Organizing your code into distinct functional modules helps in managing development of complex applications, and in designing for reusability. In addition, this technique lets you take advantage of _lazy-loading_—that is, loading modules on demand—in order to minimize the amount of code that needs to be loaded at startup.
+
+
+
+## What's next
+
+You've learned the basics about the main building blocks of an Angular application. The following diagram shows how these basic pieces are related.
-
-
-Angular apps are modular and Angular has its own modularity system called _NgModules_.
-
-NgModules are a big deal.
-This page introduces modules; the [NgModules](guide/ngmodules) pages
-relating to NgModules covers them in detail.
-
-
-
-Every Angular app has at least one NgModule class, [the _root module_](guide/bootstrapping "Bootstrapping"),
-conventionally named `AppModule`.
-
-While the _root module_ may be the only module in a small application, most apps have many more
-_feature modules_, each a cohesive block of code dedicated to an application domain,
-a workflow, or a closely related set of capabilities.
-
-An NgModule, whether a _root_ or _feature_, is a class with an `@NgModule` decorator.
+* [Modules](guide/architecture-modules)
+* [Components](guide/architecture-components)
+ * [Templates](guide/architecture-components#templates-and-views)
+ * [Metadata](guide/architecture-components#component-metadata)
+ * [Data binding](guide/architecture-components#data-binding)
+ * [Directives](guide/architecture-components#directives)
+ * [Pipes](guide/architecture-components#pipes)
+* [Services and dependency injection](guide/architecture-services)
-
-Angular ships as a collection of JavaScript modules. You can think of them as library modules.
-
-Each Angular library name begins with the `@angular` prefix.
-
-You install them with the **npm** package manager and import parts of them with JavaScript `import` statements.
-
-
-
-For example, import Angular's `Component` decorator from the `@angular/core` library like this:
-
-
-
-## Components
-
-
-
-A _component_ controls a patch of screen called a *view*.
-
-For example, the following views are controlled by components:
-
-* The app root with the navigation links.
-* The list of heroes.
-* The hero editor.
-
-You define a component's application logic—what it does to support the view—inside a class.
-The class interacts with the view through an API of properties and methods.
-
-{@a component-code}
-
-For example, this `HeroListComponent` has a `heroes` property that returns an array of heroes
-that it acquires from a service.
-`HeroListComponent` also has a `selectHero()` method that sets a `selectedHero` property when the user clicks to choose a hero from that list.
-
-
-
-## Templates
-
-
-
-You define a component's view with its companion **template**. A template is a form of HTML
-that tells Angular how to render the component.
-
-A template looks like regular HTML, except for a few differences. Here is a
-template for our `HeroListComponent`:
-
-` and `
-
-Notice how `
-
-## Metadata
-
-
-
-Metadata tells Angular how to process a class.
-
-
-
-[Looking back at the code](guide/architecture#component-code) for `HeroListComponent`, you can see that it's just a class.
-There is no evidence of a framework, no "Angular" in it at all.
-
-In fact, `HeroListComponent` really is *just a class*. It's not a component until you *tell Angular about it*.
-
-To tell Angular that `HeroListComponent` is a component, attach **metadata** to the class.
-
-In TypeScript, you attach metadata by using a **decorator**.
-Here's some metadata for `HeroListComponent`:
-
-
-
-The metadata in the `@Component` tells Angular where to get the major building blocks you specify for the component.
-
-The template, metadata, and component together describe a view.
-
-Apply other metadata decorators in a similar fashion to guide Angular behavior.
-`@Injectable`, `@Input`, and `@Output` are a few of the more popular decorators.
-
-
-
-The architectural takeaway is that you must add metadata to your code
-so that Angular knows what to do.
-
-
-
-## Data binding
-
-Without a framework, you would be responsible for pushing data values into the HTML controls and turning user responses
-into actions and value updates. Writing such push/pull logic by hand is tedious, error-prone, and a nightmare to
-read as any experienced jQuery programmer can attest.
-
-
-
-Angular supports **data binding**,
-a mechanism for coordinating parts of a template with parts of a component.
-Add binding markup to the template HTML to tell Angular how to connect both sides.
-
-As the diagram shows, there are four forms of data binding syntax. Each form has a direction — to the DOM, from the DOM, or in both directions.
-
-
-
-The `HeroListComponent` [example](guide/architecture#templates) template has three forms:
-
-
-
-
-
-## Directives
-
-
-
-Angular templates are *dynamic*. When Angular renders them, it transforms the DOM
-according to the instructions given by **directives**.
-
-A directive is a class with a `@Directive` decorator.
-A component is a *directive-with-a-template*;
-a `@Component` decorator is actually a `@Directive` decorator extended with template-oriented features.
-
-
-
-## Services
-
-
-
-_Service_ is a broad category encompassing any value, function, or feature that your application needs.
-
-Almost anything can be a service.
-A service is typically a class with a narrow, well-defined purpose. It should do something specific and do it well.
-
-
-Examples include:
-
-* logging service
-* data service
-* message bus
-* tax calculator
-* application configuration
-
-There is nothing specifically _Angular_ about services. Angular has no definition of a service.
-There is no service base class, and no place to register a service.
-
-Yet services are fundamental to any Angular application. Components are big consumers of services.
-
-Here's an example of a service class that logs to the browser console:
-
-
-
-## Dependency injection
-
-
-
-_Dependency injection_ is a way to supply a new instance of a class
-with the fully-formed dependencies it requires. Most dependencies are services.
-Angular uses dependency injection to provide new components with the services they need.
-
-
-
-Angular can tell which services a component needs by looking at the types of its constructor parameters.
-For example, the constructor of your `HeroListComponent` needs a `HeroService`:
-
-
-
-
-
-## Wrap up
-
-You've learned the basics about the eight main building blocks of an Angular application:
-
-* [Modules](guide/architecture#modules)
-* [Components](guide/architecture#components)
-* [Templates](guide/architecture#templates)
-* [Metadata](guide/architecture#metadata)
-* [Data binding](guide/architecture#data-binding)
-* [Directives](guide/architecture#directives)
-* [Services](guide/architecture#services)
-* [Dependency injection](guide/architecture#dependency-injection)
-
-That's a foundation for everything else in an Angular application,
-and it's more than enough to get going.
-But it doesn't include everything you need to know.
-
-Here is a brief, alphabetical list of other important Angular features and services.
-Most of them are covered in this documentation (or soon will be).
-
-> [**Animations**](guide/animations): Animate component behavior
-without deep knowledge of animation techniques or CSS with Angular's animation library.
-
-> **Change detection**: The change detection documentation will cover how Angular decides that a component property value has changed,
-when to update the screen, and how it uses **zones** to intercept asynchronous activity and run its change detection strategies.
-
-> **Events**: The events documentation will cover how to use components and services to raise events with mechanisms for
-publishing and subscribing to events.
-
-> [**Forms**](guide/forms): Support complex data entry scenarios with HTML-based validation and dirty checking.
-
-> [**HTTP**](guide/http): Communicate with a server to get data, save data, and invoke server-side actions with an HTTP client.
-
-> [**Lifecycle hooks**](guide/lifecycle-hooks): Tap into key moments in the lifetime of a component, from its creation to its destruction,
-by implementing the lifecycle hook interfaces.
-
-> [**Pipes**](guide/pipes): Use pipes in your templates to improve the user experience by transforming values for display. Consider this `currency` pipe expression:
->
-> > `price | currency:'USD':true`
->
-> It displays a price of 42.33 as `$42.33`.
-
-> [**Router**](guide/router): Navigate from page to page within the client
- application and never leave the browser.
-
-> [**Testing**](guide/testing): Run unit tests on your application parts as they interact with the Angular framework
-using the _Angular Testing Platform_.
diff --git a/aio/content/images/guide/architecture/compilation-context.png b/aio/content/images/guide/architecture/compilation-context.png
new file mode 100644
index 00000000000..1fdff502854
Binary files /dev/null and b/aio/content/images/guide/architecture/compilation-context.png differ
diff --git a/aio/content/images/guide/architecture/view-hierarchy.png b/aio/content/images/guide/architecture/view-hierarchy.png
new file mode 100644
index 00000000000..1127e48f2e0
Binary files /dev/null and b/aio/content/images/guide/architecture/view-hierarchy.png differ
diff --git a/aio/content/navigation.json b/aio/content/navigation.json
index 243524326fd..abd48b31422 100644
--- a/aio/content/navigation.json
+++ b/aio/content/navigation.json
@@ -125,13 +125,39 @@
"tooltip": "The fundamentals of Angular",
"children": [
{
- "url": "guide/architecture",
"title": "Architecture",
- "tooltip": "The basic building blocks of Angular applications."
+ "tooltip": "The basic building blocks of Angular applications.",
+ "children": [
+ {
+ "url": "guide/architecture",
+ "title": "Architecture Overview",
+ "tooltip": "Basic building blocks of Angular applications."
+ },
+ {
+ "url": "guide/architecture-modules",
+ "title": "Intro to Modules",
+ "tooltip": "About NgModules."
+ },
+ {
+ "url": "guide/architecture-components",
+ "title": "Intro to Components",
+ "tooltip": "About Components, Templates, and Views."
+ },
+ {
+ "url": "guide/architecture-services",
+ "title": "Intro to Services and DI",
+ "tooltip": "About services and dependency injection."
+ },
+ {
+ "url": "guide/architecture-next-steps",
+ "title": "Next Steps",
+ "tooltip": "Beyond the basics."
+ }
+ ]
},
{
- "title": "Template & Data Binding",
- "tooltip": "Template & Data Binding",
+ "title": "Components & Templates",
+ "tooltip": "Building dynamic views with data binding",
"children": [
{
"url": "guide/displaying-data",