In all fairness, we have already tackled a good number of the common concerns that modern web developers confront when building applications, small and large alike, nowadays. Therefore, it makes sense to define an architecture that will separate the aforementioned concerns into separate domain folders, catering to media assets and shared code units.

Angular's approach to separating the code and assets into logical units is by organizing them into different folders, but also by introducing the concept of an Angular module. It is in these modules that the constructs are registered. By introducing modules, a lot of the noise have disappeared from our components and our components are free to use the other constructs of the same module and, in some cases, constructs from other modules, given that their containing module is imported first.

It's worth emphasizing that when we are talking about Angular modules, we mean the @NgModule decorator and when we otherwise talk about modules, we mean the ES2015 construct.

Sometimes, two contexts may require sharing the same entities, and that is fine (as long as it does not become a common thing in our project, which would denote a serious design issue). Also worth emphasizing is that we use the word context to describe a logical boundary of constructs. A context is best kept within an Angular module. So, every time the word context is used, think that it will in code translate to an Angular module.

The following example, applied to our previous work on Pomodoro components, depicts this scheme, essentially making out our entire application of contexts and different constructs:

• Task context:
  • Task module
  • Task model
  • Tasks service
  • Task table component
  • Task pomodoros component
  •  Task tooltip directive
• Timer context:
  • Timer module 
  • Timer feature
  • Timer component
• Admin context:
  • Admin module 
  • Authentication service
  •  Login component
  •  Editor component
• Shared context:
  • Shared module
  • Components shared across features
  •  Pipes shared across features
  • Directives shared across features
  • Global models and services
  •  Shared media assets

As we can see, the first step is to define the different features our application needs, keeping in mind that each one should make sense on its own in isolation from the others. Once we define the set of features required, we will create a module for each one. Each module will then be filled with the components, directives, pipes, models, and services that shape the feature it represents. Always remember the principles of encapsulation and reusability when defining your features set.

Initially, when starting your project, you should name your constructs after what they are, so say we have the Admin context, it should look something like this:

//admin/

admin.module.ts
authentication.service.ts
login.component.ts
editor.component.ts

With a quick glance, you should be able to see what the construct contains, so use a naming standard that looks like this:

<name>.<type>.ts // example login.service.ts

This is not the only way to do it, of course. There is another perfectly acceptable way of doing it, namely to create subdirectories for each type, so your preceding admin directory could look like this instead:

//admin/

admin.module.ts
services/
  authentication.service.ts
components/
  login.component.ts
  login.component.html
  editor.component.ts
  create-user.component.ts
pipes/
  user.pipe.ts

It is worth noting that you should keep the type in the filename for clarity in debugging. Otherwise, when looking for a specific file to set a breakpoint in your browser, let's say the login service, it might be quite confusing if you start typing login.ts and you are presented with:

• components/login.ts
• services/login.ts
• pipes/login.ts

There is an official style guide in place for how you should organize your code and how to name your constructs. There are definitely benefits to following a guide; it's easy for newcomers, the code looks more consistent, and so on. You can read more here; https://angular.io/guide/styleguide. Remember that whether you choose to follow this style guide in its entirety or not, consistency is key as it will make it easier to maintain the code.