Skip to main content

📜 ADR

Bu bölüm, projelerimizin mimarisini şekillendiren kritik kararların kronolojik bir günlüğüdür. Sadece neye karar verdiğimizi değil, neden o kararı aldığımızı ve o anki bağlamı belgeleriz.

🎯 Neden ADR Tutuyoruz?​

  1. Hafıza Kaybını Önlemek: Altı ay sonra "Neden bu veritabanını seçtik?" dediğimizde cevabı burada buluruz.
  2. Onboarding Desteği: Yeni katılan arkadaşlarımız, sistemin evrimini ve arkasındaki mantığı hızlıca kavrar.
  3. Hatalardan Ders Çıkarmak: Geçmişte alınan kararların sonuçlarını (pros/cons) görerek aynı hataları tekrarlamayız.
  4. Hizalama (Alignment): Teknik tartışmaları sözlü olmaktan çıkarıp, yazılı ve kalıcı bir mutabakata dönüştürürüz.

🚦 Karar Durumları (Status)​

Her karar belgesi aşağıdaki durumlardan birine sahip olmalıdır:

  • 🟡 Proposed: Tartışma aşamasında, henüz karara bağlanmamış.
  • 🟢 Accepted: Kabul edildi ve uygulanmaya başlandı.
  • 🔴 Deprecated: Artık geçerli olmayan bir uygulama.
  • 🔵 Superseded: Başka bir karar (örn: ADR-005) tarafından geçersiz kılındı (yerine yenisi geldi).

🛠️ Yeni Bir ADR Nasıl Eklenir?​

Bir mimari değişiklik veya önemli bir kütüphane seçimi yapıldığında şu adımları izle:

  1. Şablonu Kullan: docs/adr/template.md dosyasını kopyala.
  2. İsimlendir: Dosyayı 000X-karar-basligi.md formatında adlandır (örn: 0004-switching-to-postgresql.md).
  3. PR Aç: Kararını bir Pull Request olarak gönder ve ekip arkadaşlarını olarak etiketle.

Daha detaylı bilgi için Document Style Guide bakınız.