🐈 D1 · Nest CLI ve Modül Mimarisi

D1 · Nest CLI ve Modül Mimarisi: NestJS, **TypeScript dünyasındaki Spring Boot'un ikizi** gibidir: Express'in "her şeyi elle kur" felsefesinin tam tersine, Nest yeniden "opiniona

NestJS, **TypeScript dünyasındaki Spring Boot'un ikizi** gibidir: Express'in "her şeyi elle kur" felsefesinin tam tersine, Nest yeniden "opinionated" bir yapıya döner — `@Module`, `@Controller`, `@Injectable` decorator'ları, Java'daki `@Configuration`, `@RestController`, `@Service`'in neredeyse birebir çevirisidir. Bir modül (`AppModule`), hangi controller'ların ve provider'ların (servislerin) birbirine bağlı olduğunu bir Spring `@Configuration` sınıfı gibi bildirir; Nest'in kendi DI (dependency injection) container'ı bunları senin yerine "bağlar". Peki Express'ten sonra neden tekrar bir "iskelet/disiplin" katmanına dönülüyor? Çünkü küçük bir prototipte özgürlük hız kazandırır, ama büyük bir takımda (5, 10, 50 geliştirici) HERKESİN aynı klasör yapısını, aynı hata yönetimini, aynı DI mantığını kullanması gerekir — Nest bunu bir framework kararı olarak dayatır, tıpkı Spring'in yaptığı gibi. Bir Java geliştiricisi Nest'i ilk gördüğünde kendini EVİNDE hisseder: sınıflar, decorator'lar, constructor injection — hepsi tanıdıktır. Tester için önemli olan: modül kaydı (bir controller'ın `@Module`'e EKLENMESİ) Express'teki route tanımından FARKLI bir hata sınıfı doğurur — kodun kendisi doğru olsa bile, modüle kayıtlı değilse o route hiç VAR OLMAZ.

İskelet: Modül + Bootstrap

**🐞 Defect Doğum Anı — `BugsController` `@Module`'e eklenmezse** **Kod:** `bugs.controller.ts` dosyası tamamen doğru yazıldı (`@Controller`, `@Get()` decorator'ları hepsi doğru), ama `app.module.ts`'teki `controllers: [...]` dizisine EKLENMEDİ. **Ne olur:** Uygulama HATASIZ başlar (TypeScript derleyicisi bunu bir hata olarak görmez — sınıf hâlâ geçerli bir sınıftır), ama Nest'in DI container'ı bu controller'dan HİÇ haberdar olmaz. `GET /api/v1/bugs` request'i atıldığında Nest'in kendi varsayılan 404'ü döner — sanki route hiç yazılmamış gibi. **Neden sinsi:** Bir code review'da dosyayı açan biri "controller doğru yazılmış" der ve geçer — çünkü dosyanın İÇİ gerçekten doğrudur. Eksik olan tek satır, başka bir dosyadaki (`app.module.ts`) bir DİZİ elemanıdır; bu, "doğru kod, yanlış yerde kayıtlı değil" kategorisinin NestJS'teki karşılığıdır. **Tester nerede yakalar:** Code review "her şey doğru görünüyor" dese bile, gerçek bir request atıp 404 alınca — bu, "kod incelemesi yeterli değildir, çalışan sistemde doğrulama şarttır" prensibinin somut kanıtıdır.

🎬 Doğru Kod, Kayıtsız Controller

BugsController (doğru kod)

@Module({ controllers })

404 aldı, koda baktı: doğruydu

Geliştirici `bugs.controller.ts`'i baştan sona doğru yazıyor — decorator'lar, metotlar, hepsi tamam.

Normalde bu controller `@Module({ controllers: [BugsController] })` dizisine EKLENMELİ.

Bu adım ATLANIRSA, Nest'in DI container'ı bu controller'dan HİÇ haberdar olmaz — TypeScript derleyicisi de bunu bir hata saymaz.

`GET /api/v1/bugs` request'i atılır — route TANIMLI olsa da DI container'a KAYITLI olmadığı için Nest 404 döner.

Ders — Kod incelemesi "dosya doğru yazılmış" der ama çalışan sistemde route yoktur. Tester her zaman gerçek bir request'le doğrular.

Bir Controller'ın "Var Olma" Yolculuğu

@Controller() ve @Get() decorator'larıyla BugsController'ı yaz — bu TEK BAŞINA yeterli değildir.