რა არის მოდულები NestJS-ში?

Question

Accepted Answer

**მოდული** არის კლასი, რომელიც დეკორირებულია `@Module()`-ით და **დაკავშირებული კომპონენტებს გაერთიანებს** — კონტროლერებს, პროვაიდერებს/სერვისებს — ერთ კოჰერენტულ ერთეულში. მოდულები წარმოადგენს NestJS-ის აპლიკაციის ორგანიზების მეთოდს ფიჩარებად, და ყველა Nest აპლიკაციას აქვს მინიმუმ ერთი root `AppModule`.

## მოდულის განსაზღვრა

```ts
import { Module } from "@nestjs/common";

@Module({
  controllers: [UsersController],    // controllers belonging to this module
  providers: [UsersService],          // providers (services) this module creates
  imports: [DatabaseModule],          // OTHER modules whose exports this module needs
  exports: [UsersService],            // what this module makes available to importers
})
export class UsersModule {}
```

## ოთხი ძირითადი თვისება

```text
controllers → the controllers (request handlers) in this module
providers   → the providers/services defined and instantiated here (for DI)
imports     → other modules whose EXPORTED providers this module can use
exports     → the subset of THIS module's providers shared with importing modules
```

მოდულები ქმნიან **DI scope**: პროვაიდერი ხელმისაწვდომია თავის მოდულის ფარგლებში და სხვა მოდულებისთვის მხოლოდ იმ შემთხვევაში, თუ ის **ექსპორტირებული** იქნება (და სხვა მოდული მას **იმპორტირებს**).

## root მოდული

```ts
@Module({
  imports: [UsersModule, AuthModule, DatabaseModule],   // compose feature modules
})
export class AppModule {}   // the root — bootstrapped to start the app
```

ყველა აპლიკაციას აქვს root `AppModule`, რომელიც იმპორტირებს ფიჩარის მოდულებს, მთელი აპლიკაციის კომპოზიციას განსაზღვრავს.

## ფიჩარზე დაფუძნებული ორგანიზაცია

```text
src/
  app.module.ts            (root — imports feature modules)
  users/
    users.module.ts        (groups users controller + service)
    users.controller.ts
    users.service.ts
  auth/
    auth.module.ts
  database/
    database.module.ts     (shared infrastructure)
```

კონვენცია არის **ერთი მოდული ერთ ფიჩარზე/დომენზე** (მომხმარებლები, ავტორიზაცია, პროდუქტები), დაკავშირებული კოდი ერთად ინახება და დამოკიდებულებები მკაფიოა.

## პროვაიდერების გაზიარება მოდულებს შორის

```ts
// UsersModule exports UsersService...
@Module({ providers: [UsersService], exports: [UsersService] })
export class UsersModule {}

// ...so AuthModule can use it by importing UsersModule
@Module({ imports: [UsersModule] })   // now AuthModule can inject UsersService
export class AuthModule {}
```

მოდულიდან პროვაიდერის გამოსაყენებლად, მომწოდებელი მოდული აუცილებლად უნდა **ექსპორტირებდეს** მას და მოხმარებელი მოდული უნდა **იმპორტირებდეს** მომწოდებელი მოდულს — ეს დამოკიდებულებებს მკაფიოს ხდის.

## რატომ მნიშვნელოვანია ეს

მოდულები წარმოადგენს ყველა NestJS აპლიკაციის ორგანიზაციის ხერხემალს — ისინი დაკავშირებულ კონტროლერებს და პროვაიდერებს გაერთიანებენ კოჰერენტული ფიჩარის ერთეულებში და განსაზღვრავენ dependency-injection საზღვრებს.

ja ოთხი თვისების (`controllers`, `providers`, `imports`, `exports`) გაგება და განსაკუთრებით **იმპორტ/ექსპორტის მექანიზმი** პროვაიდერების გაზიარებისთვის მოდულებს შორის აუცილებელია: ეს არის კერძოდ როგორ მიაღწევს NestJS მოდულარული, თავისუფლად დაკავშირებული არქიტექტურა, სადაც თითოეული ფიჩარი თვითორიენტირებული და დამოკიდებულებები მკაფიოა.

ფიჩარზე დაფუძნებული მოდულის სტრუქტურა (ერთი მოდული დომენზე) არის სტანდარტული გზა Nest აპლიკაციების ორგანიზებისთვის სკალაბილურობისა და შენარჩუნებისთვის.

მოდულები, კონტროლერებთან და პროვაიდერებთან ერთად, ქმნიან NestJS-ის ძირითად არქიტექტურას, რომელიც მათ ფундამენტურ ცოდნად აქცევს — უნდა გესმოდეთ თუ როგორ სტრუქტურირებულიყო აპლიკაცია მოდულებში და როგორ აკავშირებთ პროვაიდერებს მოდულებს შორის იმპორტ/ექსპორტის მეშვეობით — ეს აუცილებელია ნებისმიერი არატრივიალური NestJS აპლიკაციის აგებისთვის და ხშირად გაუგებარი ადგილია, რომელიც ღირს კარგად გაკვეთილი.