Project Layout
Project layout, Domain driven development, Single Responsibility Principle

Project structure

1
happynrwl/
2
├── apps/
3
├── libs/
4
│ ├── happynrwlapp/
5
│ │ ├── registration/
6
│ │ │ ├── feature-main/
7
│ │ │ ├── feature-login/
8
│ │ │ ├── ui-form/
9
│ │ │ └── utils-testing/
10
│ │ ├── search/
11
│ │ │ ├── feature-results/
12
│ │ │ └── utils-testing/
13
│ │ └── shared/
14
│ │ └── ui/
15
│ ├── adminapp/
16
| └── shared/
17
│ ├── ui/
18
│ └── utils-testing/
19
├── tools/
20
├── workspace.json
21
├── nx.json
22
├── package.json
23
└── tsconfig.json
Copied!

application module types

    yeti-web-app yeti web app
    yeti-web-app-e2e yeti web app e2e testing
    yeti-mobile-app mobile version of yeti app
    yeti-desktop-app desktop version of yeti app
    yeti-api yeti backend API
The app.module is almost the same for the Web, Mobile and Desktop applications. It only imports the feature-shell and performs platform-specific configurations.

library module types

    workspace libraries, and package libraries(has package.json)
      workspace libraries are used only within the workspace.
      package libraries are publishable to NPM and can be used outside its workspace.
    Utility libraries contain utilities and services.
    Data-access can contain NGXS-related code and services.
    Component libraries should contain presentational components and directives.
    Feature libraries contain business logic, application screens, routable etc.

scoped library modules

    domain
      booking/data-access -- a scoped library used in single domain. contains
      booking/shell-<web/mobile...> -- shell libraries used in a single domain. can have many shell libraries in a single domain
      booking/feature-search-<web/mobile...> -- feature libraries used in single domain. can have many feature modules in a single domain
      booking/shared/ui -- a shared library used by multiple feature modules in a single domain. contains
    shared
      shared/feature-<something> -- shared feature modules used in multiple domains. Can have many feature modules in shared domain
      shared/data-access -- a shared type=angular library, contains , used across libs
      shared/environments -- a shared type=angular library, contains environments, used across libs
      shared/scss -- a shared type=universal library, contains scss, used across libs and apps
      shared/assets -- a shared type=universal library, contains static non-TypeScript assets e.g., , used across libs and apps
      shared/ui --a shared UI library used across applications
      shared/utils --a shared type=universal libraries used across applications. e.g., data structures , algorithms
    nestjs - contains nestjs shared and feature modules
      nestjs/config -- config module
      nestjs/environments -- a shared universal library, contains environments, used across libs
    components -- publishable component modules, published to NPM via Lerna. to be used by parent project as well as outside projects. modules here contains package.json
    core -- core library contains used globally, only included in application modules

Rules

    Libraries with a broader scope (e.g., shared/ui) should not depend on the libraries with narrower scope (e.g., booking/shared/ui).
    Component libraries should only depend on other component libraries and utility libraries, but should not depend feature libraries.

Info

    The shell component is the entry point component of our layout and features. Every additional route is added to the children array of the shell component route. Additional routes will be rendered by the router outlet in the shell component template.
Last modified 9mo ago