AI Çağında Mimari Karar Kaydı (ADR) Nasıl Tutulur? | Alios

AI ile Mimari Karar Kaydı (ADR) Tutma: Kararlar Slack’te Kaybolmasın (Alios)

Yazılım geliştirme dünyası, AI (Yapay Zeka) araçlarının entegrasyonuyla birlikte daha önce hiç olmadığı kadar hızlı bir karar alma döngüsüne girdi. Eskiden bir kütüphane seçimi veya veritabanı şeması değişikliği için günler süren toplantılar yapılırken, bugün bir yazılımcı Cursor veya ChatGPT'den aldığı tek bir öneriyle projenin gidişatını değiştirecek kritik bir karar alabiliyor.

Ancak bu hızın çok tehlikeli bir yan etkisi var: Kurumsal hafıza kaybı. AI önerileriyle alınan bu hızlı kararlar genellikle Slack mesajlarında, WhatsApp gruplarında veya Zoom toplantılarının uçucu havasında kaybolup gidiyor. Altı ay sonra projeye yeni bir ekip üyesi katıldığında veya mevcut sistemde bir performans sorunu çıktığında kimse şu sorunun cevabını veremiyor: "Neden bu yapıyı seçmiştik?"

İşte bu noktada Alios ve Mimari Karar Kaydı (Architectural Decision Record - ADR) disiplini devreye giriyor. Kararların Slack kanallarında sönüp gitmesine izin vermemek için Alios'u projenizin "Dijital Omurgası" ve "Karar Arşivi" olarak konumlandırmanız gerekiyor.

1. AI Çağında Karar Enflasyonu ve Kaybolan Hafıza

AI araçları sadece kod yazmıyor; aynı zamanda mimari tavsiyeler veriyor. "Şu mikroservisi Go ile yazarsan daha performanslı olur" veya "Veri yapısı için MongoDB yerine PostgreSQL'in JSONB özelliğini kullan" gibi öneriler saniyeler içinde karşımıza çıkıyor.

Sorunlar:

1. Karar Sayısının Artması: AI sayesinde deneme-yanılma hızı arttığı için her hafta onlarca mikro-karar alınıyor.

2. Karar Dağınıklığı: Kararların alındığı an ile koda döküldüğü an arasında bir dokümantasyon köprüsü kurulmuyor.

3. "Neden" Sorusunun Cevapsız Kalması: Kodun ne yaptığı görünür olsa da, neden o şekilde yapıldığı (mimari gerekçe) genellikle yazılımcının zihninde kalıyor ve o kişi işten ayrıldığında bilgi buharlaşıyor.

Alios, bu kararları bir Node (Düğüm) olarak sistemin merkezine sabitler. Her mimari karar, projenin iş ağacında (Tree View) somut, aranabilir ve geri dönülebilir birer kayıt haline gelir.

2. Alios Üzerinde ADR Formatı: Standartlaştırma

Mimari kararların bir "hikayesi" olmalıdır. Alios üzerinde bir Mimari Karar Node'u açtığınızda, açıklama kısmında şu standart ADR (Architectural Decision Record) formatını kullanmak, ekibin teknik vizyonunu korumasını sağlar:

ADR Şablonu:

• Tarih: Kararın alındığı gün.

• Bağlam (Context): Kararı tetikleyen teknik sorun veya ihtiyaç nedir?

• Seçenekler: Değerlendirilen alternatif yollar nelerdir? (AI'nın önerdiği alternatifler dahil).

• Karar: Hangi seçenek seçildi ve neden?

• Sonuçlar: Bu kararın sistem üzerindeki olumlu ve olumsuz etkileri neler olacak? (Teknik borç, performans, öğrenme eğrisi vb.)

• Bağlantılar: İlgili Slack tartışmaları, AI prompt çıktıları veya teknik döküman linkleri.

3. Örnek Bir ADR Kaydı (Alios Üzerinde Doldurulmuş)

Gelin, gerçek bir senaryoyu Alios formatına dökelim. Projemizde yüksek trafikli bir bildirim (notification) sistemi kuracağımızı varsayalım.

Düğüm Adı (Node): [ADR-004] Bildirim Kuyruğu İçin Redis Yerine RabbitMQ Seçimi Kaptan (Owner): @teknik_lider Statü: DONE / ARCHIVED

[ADR-004] Mimari Karar Detayı

Tarih: 13 Mart 2026

Bağlam (Context): Sistemimiz saniyede ortalama 5.000 anlık bildirim (push notification) gönderme ihtiyacı duyuyor. Mevcut yapımızda geçici bir çözüm olarak Redis List kullanıyorduk. Ancak mesajların kaybolma riski (at-least-once delivery garantisi olmaması) ve karmaşık yönlendirme (routing) kuralları gereksinimi nedeniyle daha profesyonel bir mesaj kuyruğu (message broker) sistemine geçme kararı alındı. AI (Claude-4) analizi, veri tutarlılığı önceliğimiz olduğu için bir geçiş önerdi.

Seçenekler:

1. Redis (Mevcut): Hızlı, kullanımı kolay ancak mesaj garantisi düşük.

2. Apache Kafka: Çok yüksek ölçeklenebilirlik, ancak kurulum ve yönetim maliyeti ekibimiz için şu aşamada çok yüksek.

3. RabbitMQ: Veri tutarlılığı yüksek, gelişmiş yönlendirme özellikleri var ve ekibimizin yönetebileceği karmaşıklıkta.

Karar: RabbitMQ seçildi. Sebebi; mesajların mutlaka iletilmesi (ack/nack mekanizması) zorunluluğumuz ve farklı bildirim tiplerini (SMS, E-posta, Push) farklı kuyruklara yönlendirmek için sunduğu "Exchange" yapısının esnekliğidir. AI simülasyonları, 10.000 TPS altında RabbitMQ'nun bizim için en verimli maliyet/performans dengesini sunduğunu doğruladı.

Sonuçlar:

• Olumlu: Mesaj kaybı riski minimize edildi. Sistem modüler hale geldi.

• Olumsuz: Mevcut altyapıya yeni bir servis (RabbitMQ Cluster) eklendiği için DevOps bakım yükü %15 arttı.

• Teknik Borç: Gelecekte trafik saniyede 100.000'i geçerse Kafka'ya geçiş tekrar değerlendirilmeli.

Bağlantılar:

• [Slack Tartışma Arşivi - #tech-architecture-channel]

• [AI Karar Matrisi Analiz Çıktısı - PDF]

• [RabbitMQ Entegrasyon Taskı - @Node-125]

4. Alios ile Karar Takibi Neden Fark Yaratır?

1. Arama ve Bulunabilirlik: Slack'te bir kararı bulmak için anahtar kelimelerle boğuşursunuz. Alios'ta "ADR" etiketiyle arama yaptığınızda, projenin tüm teknik anayasası kronolojik olarak önünüze gelir.

2. İşle İlişkilendirme: Mimari kararı içeren Node'u, o kararın uygulandığı Geliştirme Taskları (Nodes) ile birbirine bağlayabilirsiniz. Kod yazan kişi, Alios ağacında bir üst düğüme baktığında neden bu kodu yazdığını anında görür.

3. Yeni Personel Oryantasyonu: Yeni bir yazılımcı işe başladığında "Neden her şey RabbitMQ ile yapılmış?" diye sorduğunda, ona ADR listesini vermeniz yeterlidir. Bu, saatlerce süren açıklama yükünü ortadan kaldırır.

5. Sonuç: Söz Uçar, Alios Kalır

AI bize sınırsız fikir ve hız sunuyor, ancak bu hızı kurumsal bir değere dönüştürmek "kayıt tutma" disipliniyle mümkündür. Mimari kararlarınızı Slack'in tozlu raflarına veya yazılımcıların zihinlerine hapsetmeyin.

Alios üzerinde tutulan her ADR, projenizin geleceğine bırakılmış bir mektuptur. Kodunuzu AI yazabilir, ama mimarinizi ve kararlarınızı Alios yönetmelidir.