NestJS'te Özellik Modülleriyle Uygulamayı Parçalara Ayırmak

// apps/api/src/app.module.ts
@Module({
  imports: [
    ConfigModule.forRoot({ isGlobal: true, envFilePath: [...] }),
    PrismaModule,
    StorageModule,
    ProjectsModule,
    PostsModule,
    SettingsModule,
  ],
  controllers: [AppController],
  providers: [AppService],
})
export class AppModule {}

Her kaynak (posts, projects, settings, storage) kendi klasöründe kendi controller/service/module üçlüsüne sahip. AppModule bunları tek tek import ediyor — kendisi iş mantığı içermiyor, sadece bir araya getiriyor.

Modül sınırı neden dosya klasörlemekten fazlası

NestJS'te bir modül sadece bir klasörleme kolaylığı değil — @Module({ controllers, providers, exports }) decoratorı, o özelliğin bağımlılık grafiğini (dependency graph) tanımlıyor. PostsModule, PostsService'i providers'a koyup export etmediği sürece, başka bir modül PostsService'i inject edemez. Bu sınır, "her şey her şeye erişebilir" durumunu engelliyor — ProjectsModule'ün PostsService'e ihtiyacı yoksa, onu asla göremiyor bile.

PrismaModule/StorageModule neden ayrı, posts/projects gibi bir "kaynak" değilken

Prisma ve MinIO storage, iş kaynağı değil altyapı — her feature modülünün ihtiyaç duyabileceği paylaşılan servisler. Ayrı modül olarak var olmaları, PostsModule ve ProjectsModule'ün ikisinin de PrismaService'i kendi providers'ında tekrar tanımlamak yerine, tek bir PrismaModule'den import edip aynı (tekil) PrismaService instance'ını paylaşmasını sağlıyor.

Yeni bir kaynak eklemek ne gerektiriyor

Yeni bir Comments kaynağı eklemek istersen: comments.controller.ts, comments.service.ts, comments.module.ts üçlüsünü oluşturup AppModule'ün imports listesine tek satır eklemek yeterli. Var olan hiçbir modülün içine dokunmadan sistem genişliyor — modüler sınırların asıl kazancı bu: değişikliğin etki alanı, dosya sayısıyla değil, modül sınırlarıyla ölçülüyor.