In the previous chapters and sections in this chapter, we have seen different approaches and good practices for laying out Angular 2 applications. These guidelines encompassed from naming conventions to pointers about how to organize files and folders. From this point onwards, we are going to put all this knowledge to practice by refactoring all the different interfaces, components, directives, pipes, and services in an actual Angular 2 architecture, conforming to the most commonly agreed community conventions.

By the end of this chapter, we will have a final application layout that wraps everything we have seen so far in the following site architecture:

.
├── app/
│   ├── shared/ 
│   │   ├── assets/ ← Global CSS or image files are stored here
│   │   ├── directives/
│   │   ├── interfaces/
│   │   ├── pipes/
│   │   ├── services/
│   │   └── shared.ts ← facade for the 'shared' context
│   ├── tasks/
│   │   ├── (tasks-related components and directives)
│   │   └── tasks.ts ← facade for the 'tasks' context
│   ├── timer/
│   │   ├── (timer-related components and directives)
│   │   └── timer.ts ← facade for the 'timer' context
│   │   
│   ├── app.component.ts ← top root application component
│   └── main.ts ← here we bootstrap the top root component
│      
├── index.html
├── package.json
├── tsconfig.json
└── typings.json      

It is easy to understand the whole rationale of the project. Now, we will put together an application that features two main contexts: a timer feature and a tasks listing feature. Each feature can encompass a different range of components, pipes, directives, or services. The inner implementation of each feature is opaque to the other features or contexts. Each feature context exposes a facade that exports the pieces of functionality (that is, the component, one or many) that each context delivers to the upper-level context or application. All the other pieces of functionality (inner services or directives) are concealed from the rest of the application.

It is fair to say that it is difficult to draw a line in the sand differentiating what belongs to a specific context or another. Sometimes, we build pieces of functionality, such as certain directives or pipes, which can be reused throughout the application. So, locking them down to a specific context does not make much sense. For those cases, we do have the shared context, where we store any code unit which is meant to be reusable at an application level, apart from media files such as style sheets or bitmap images that are component-agnostic.

The main app.component.ts file contains and exports the application root component, which declares and registers in its own injector the dependencies required by its child components. As you know already, all Angular 2 applications must have at least one root component, initialized by the bootstrap() function. This operation is actually performed in the main.ts file, which is fired by the index.html file.

Defining a component or a group of related components within a context like this improves reusability and encapsulation. The only component that is tightly coupled with the application is the top root component, whose functionality is usually pretty limited and entails basically rendering the other child components in its template view or acting as a router component, as we will see in the next chapters.

The last bit of the puzzle is the JSON files that contain the TypeScript compiler, typings, and npm configuration. Since versioning on the Angular 2 framework keeps evolving, we will not look at the actual content of these files here. You are supposed to know their purpose, but some specifics such as the peer dependency versions change quite often so you better refer to the book's GitHub repository for the latest up-to-date version of each one. The package.json file requires a special mention though. There are a few common industry conventions and popular seed projects, like the one provided by the Angular official site itself. We have provided several npm commands to ease the overall installation process and the development endeavor: