AI Çağında Domain Analizi

Bir özelliği yazdırmanın maliyeti saatlerden dakikalara inince, yanlış özelliği yazdırmanın maliyeti göreli olarak büyüdü. Ajan, belirsiz bir isteği kendinden emin bir şekilde somut koda çevirir; 'sipariş iptali' istediğinizde kısmi iptal, iade ve stok geri alma arasındaki farkı sizin yerinize, sormadan seçer.

Bu yüzden domain analizinin değeri artıyor. Analiz, ekibin şu sorulara ortak cevap vermesini sağlar: Hangi kavramlar var ve tam olarak ne anlama geliyorlar? Hangi kurallar asla çiğnenmemeli? Hangi süreçler hangi olaylarla tetikleniyor? Kim neyin sahibi? Somut bir eşik: bir özellik için iş birimi ile mühendislik aynı terimi iki farklı anlamda kullanıyorsa (ör. 'aktif müşteri' satışta son 90 günde alım yapan, destekte açık bileti olan), koda geçmeden önce o terimin bölünmesi gerekir. Aksi halde ajan hangisini seçtiyse o kodda yaşar.

Son on iki ayda ajanla kod yazmak ana akım oldu. Stack Overflow'un 6 Ekim 2026'da yayımlanan ve 30 binden fazla katılımcıya dayanan anketinde geliştiricilerin yüzde 66'sı coding agent kullanıyor; AI çıktısına güvenmek için kaynak gösterilmesini şart koşanların oranı yüzde 93. DORA'nın 2026 başında yayımlanan 'ROI of AI-Assisted Software Development' raporu, aktardığı Stanford araştırmasıyla AI'ın basit greenfield işlerde yüzde 35-40 verimlilik kazancı sağladığını, karmaşık legacy kodda ise bunun yüzde 10 ya da altında kaldığını söylüyor; rapor bunu AI çıktısını doğrulamanın getirdiği 'verification tax' ile birlikte okuyor. Kısacası kazanç, problemin iyi anlaşıldığı yerde yoğunlaşıyor.

DDD topluluğu da bu soruyu merkeze aldı. Eric Evans, Haziran 2026'daki DDD Europe açılış konuşmasında domain modellerinin ve bounded context'lerin önemini koruyacağı hipotezini ve LLM ile deterministik hesabı birleştirip koddan domain sözlüğü çıkaran deneyini anlattı; Chelsea Troy da bounded context sezgisini LLM ile çalışırken bağlam yönetimi için önerdi. Vaughn Vernon, Mayıs 2026'da coding agent'ların ayrıntılı yönlendirmeye rağmen CRUD'a kaydığını aktardı. Thoughtworks'ün Nisan 2026 Radar'ı ise kararların gerekçesini sorgulanabilir tutan 'context graph' tekniğini 'Assess' halkasına aldı.

Event storming, Alberto Brandolini'nin geliştirdiği, iş uzmanları ve geliştiricilerin bir duvar (ya da Miro gibi dijital bir tahta) önünde iş sürecini domain event'leri üzerinden keşfettiği atölye formatı. Turuncu yapışkan notlara geçmiş zamanlı olaylar yazılır ('Sipariş verildi', 'Ödeme reddedildi'), sonra zaman çizgisine dizilir, ardından komutlar, aktörler, politikalar ve dış sistemler eklenir. Çelişkiler ve bilinmeyenler 'hot spot' olarak işaretlenir.

Gücü, farklı kişilerin kafasındaki farklı süreç modellerini birkaç saat içinde görünür kılması. Big picture formatında 10-15 kişilik bir atölye genelde yarım gün ile bir gün sürer. Anti-pattern: atölyeyi yalnızca geliştiricilerle yapmak. Event storming'in değeri, depo sorumlusunun 'aslında o adım hiç böyle işlemiyor' dediği andan gelir; bu cümleyi ne bir LLM ne de dokümantasyon üretir.

Bounded context, bir modelin ve onun terimlerinin tutarlı olduğu sınır. Aynı kelime iki bağlamda farklı anlama gelebilir ve bu bir hata değil, gerçekliğin kendisi. 'Ürün' katalog bağlamında açıklaması ve görselleri olan bir kayıt, stok bağlamında depo konumu ve adedi olan bir kalem, faturalama bağlamında vergi oranı olan bir satırdır.

Sınırları çizmek için kullanışlı sorular: Bu kavramı değiştirme yetkisi kimde? Bu kural hangi ekibin sorumluluğunda? Bu iki süreç farklı hızlarda mı değişiyor? DDD Crew'un Bounded Context Canvas'ı, her bağlam için amacı, ortak dili, gelen ve giden mesajları ve iş kararlarını tek sayfada toplamaya yarıyor. AI çağında ek bir fayda: bağlam sınırı, ajana verilecek bağlamın da sınırıdır. Faturalama bağlamında çalışan bir ajana katalog bağlamının tüm kurallarını vermek hem token israfı hem karışıklık kaynağıdır.

LLM'ler domain analizinde güçlü bir asistan olabilir, ama belirli işlerde. Ham materyali işlemek: toplantı transkriptleri, destek biletleri, mevcut veritabanı şeması ve eski kod tabanından aday terimler, aday event'ler ve aday kurallar çıkarmak. Event storming öncesinde 'bu 200 destek biletinde geçen süreç adımlarını geçmiş zamanlı event olarak listele' istemi, atölyeye boş duvarla değil, tartışılacak bir taslakla girmeyi sağlar.

Çelişki avı: aynı terimin farklı dokümanlarda farklı tanımlarını yan yana koymak. Soru üretimi: bir süreç için 'bu adım başarısız olursa ne olur?', 'bu kuralın istisnası var mı?' gibi sorular listesi çıkarmak. Dokümantasyon: atölye sonrası duvar fotoğrafından glossary, event kataloğu ve bağlam haritası taslağı üretmek. Ortak nokta şu: LLM bir aday üretiyor, ekip karar veriyor. Çıktıyı 'analiz sonucu' değil 'analiz girdisi' olarak etiketlemek bu ayrımı korur.

En büyük risk, LLM'in genel iş bilgisini sizin iş alanınızın gerçeği gibi sunması. Bir e-ticaret iade süreci sorduğunuzda model size endüstri ortalamasını, yani makul ama genel bir süreci anlatır. Sizin şirketinizde iadenin depo yerine mağazada onaylanıyor olması, ya da kurumsal müşterilere iade yerine alacak dekontu kesilmesi bu ortalamada yoktur. Model bunu bilmediğini de söylemez.

İkinci risk düzleştirme: LLM'ler çelişkiyi çözmeye, iki farklı tanımı tek bir 'makul' tanımda birleştirmeye eğilimli. Oysa analizde çelişki bir sinyaldir; çoğu zaman iki ayrı bounded context olduğunu gösterir. Üçüncü risk sahte tamlık ve kod tarafındaki yansıması: Vaughn Vernon'ın 2026'da aktardığı gibi, ajanlar zengin domain modeli yerine CRUD'a kayma eğiliminde; analizden gelen kurallar açıkça yazılı değilse kod onları anemik bir veri modeline indirger. Sahte tamlıkta ise model eksiksiz görünen bir event listesi üretir ve ekip boşlukları sorgulamayı bırakır. Pratik önlem: model çıktısındaki her öğeye kaynak (hangi transkript, hangi bilet) iliştirmesini isteyin; kaynağı olmayan öğe 'varsayım' olarak işaretlensin ve atölyede doğrulanmadan modele girmesin.

Domain analizinin AI çağındaki yeni tüketicisi, kodu yazan ajanın kendisi. Duvarda kalan bir event storming fotoğrafı ajan için yok hükmündedir. Analiz sonunda üretilmesi gereken minimum paket: bağlam başına glossary (terim, tanım, karıştırılmaması gereken terim), event kataloğu (ad, tetikleyen komut, taşıdığı veri), temel kurallar listesi ve bağlam haritası (hangi bağlam hangisine ne gönderiyor).

Bu paket repo içinde, sürümlenen dosyalar olarak durmalı ve ajan talimat dosyası (CLAUDE.md, AGENTS.md vb.) hangi görevde hangi bağlamın dosyalarını okuyacağını söylemeli; tüm analizi talimat dosyasına yapıştırmak, Thoughtworks'ün 2026'da uyardığı instruction bloat sorununa yol açar. Ölçülebilir bir hedef koyabilirsiniz: ajanın ürettiği PR'larda kullanılan alan ve sınıf adlarının glossary'deki terimlerle eşleşme oranı. Glossary'de 'Shipment' varken kodda 'Delivery', 'Cargo' ve 'Parcel' görüyorsanız, ya glossary eksik ya da ajan onu okumuyor. Analiz artık bir kez yapılıp rafa kalkan bir doküman değil, her görevde tüketilen bir girdi.