Modularity
Modularity
Many Small, Self Contained Modules
[Style Y160]
Create small modules that encapsulate one responsibility.
Why?: Modular applications make it easy to plug and go as they allow the development teams to build vertical slices of the applications and roll out incrementally. This means we can plug in new features as we develop them.
Create an App Module
[Style Y161]
Create an application root module whose role is to pull together all of the modules and features of your application. Name this for your application.
Why?: Angular encourages modularity and separation patterns. Creating an application root module whose role is to tie your other modules together provides a very straightforward way to add or remove modules from your application.
Keep the App Module Thin
[Style Y162]
Only put logic for pulling together the app in the application module. Leave features in their own modules.
Why?: Adding additional roles to the application root to get remote data, display views, or other logic not related to pulling the app together muddies the app module and make both sets of features harder to reuse or turn off.
Why?: The app module becomes a manifest that describes which modules help define the application.
Feature Areas are Modules
[Style Y163]
Create modules that represent feature areas, such as layout, reusable and shared services, dashboards, and app specific features (e.g. customers, admin, sales).
Why?: Self contained modules can be added to the application with little or no friction.
Why?: Sprints or iterations can focus on feature areas and turn them on at the end of the sprint or iteration.
Why?: Separating feature areas into modules makes it easier to test the modules in isolation and reuse code.
Reusable Blocks are Modules
[Style Y164]
Create modules that represent reusable application blocks for common services such as exception handling, logging, diagnostics, security, and local data stashing.
Why?: These types of features are needed in many applications, so by keeping them separated in their own modules they can be application generic and be reused across applications.
Module Dependencies
[Style Y165]
The application root module depends on the app specific feature modules and any shared or reusable modules.
Why?: The main app module contains a quickly identifiable manifest of the application’s features.
Why?: Each feature area contains a manifest of what it depends on, so it can be pulled in as a dependency in other applications and still work.
Why?: Intra-App features such as shared data services become easy to locate and share from within
app.core(choose your favorite name for this module).Note: This is a strategy for consistency. There are many good options here. Choose one that is consistent, follows Angular’s dependency rules, and is easy to maintain and scale.
My structures vary slightly between projects but they all follow these guidelines for structure and modularity. The implementation may vary depending on the features and the team. In other words, don’t get hung up on an exact like-for-like structure but do justify your structure using consistency, maintainability, and efficiency in mind.
In a small app, you can also consider putting all the shared dependencies in the app module where the feature modules have no direct dependencies. This makes it easier to maintain the smaller application, but makes it harder to reuse modules outside of this application.