Atılabilir Kod, Kalıcı Domain: Spec-Driven Development'ın Eksik Katmanı

Birgitta Böckeler'in martinfowler.com'daki sınıflandırması işe yarıyor: spec-first (görevden önce spec yaz, sonra atabilirsin), spec-anchored (spec'i özellik yaşadıkça güncel tut) ve spec-as-source (insan yalnızca spec'i düzenler, kod tamamen üretilir). Üç seviyede de spec'in birimi genellikle bir özellik ya da bir değişiklik isteği.

Sorun şu: 'İade talebi oluştur' özelliğinin spec'i iade kavramını kendi içinde tanımlıyor; altı ay sonra 'kısmi iade' özelliğinin spec'i aynı kavramı başka kelimelerle yeniden tanımlıyor. İki spec arasında kimse 'iade tutarı sipariş tutarını aşamaz' kuralını tek bir yerde tutmuyor. Eksik katman tam olarak bu: özelliklerin üstünde duran, birden fazla spec'in referans verdiği, kavramları ve kuralları bir kez tanımlayan domain modeli. Spec'ler bu modele atıf yapmalı, onu kopyalamamalı; kopyalanan her tanım bir sonraki özellikte sessizce ayrışır.

Son on iki ayda SDD araçları hızla olgunlaştı. GitHub Spec Kit, 21 Ağustos 2026'da birinci yaşında 1.0.0 sürümünü yayımladı; bakımcı blogu 130 binin üzerinde GitHub yıldızı, 150'den fazla topluluk extension'ı ve 35'ten fazla desteklenen coding agent bildiriyor. Haziran 2026'da v0.11 ile gelen `/speckit.converge` adımı, implementasyondan sonra kodun spec'le uyuşup uyuşmadığını kontrol edip kalan işi görev listesine ekliyor. Kiro, Kasım 2025'teki genel erişim sürümünden beri spec'ten property-based test üretiyor; Ekim 2026'da spec dokümanlarına toplu yorum yapılabilen Markdown Review özelliğini ekledi.

Thoughtworks Technology Radar'ın Nisan 2026 sayısı Spec Kit ve OpenSpec'i 'Assess' halkasına koydu; aynı sayıda CLAUDE.md ve AGENTS.md dosyalarının şişmesini (agent instruction bloat) 'Caution' olarak işaretledi. Kanıt tarafı karışık: Nisan 2026 tarihli 'Spec Kit Agents' çalışmasında ajana repo bağlamını besleyen hook'lar, beş puanlık kalite skorunu yalnızca 0,15 puan artırdı. Kısacası araçlar spec ile kod arasındaki uyumu ölçmeye başladı; birden fazla spec'in paylaştığı kalıcı domain katmanı ise hâlâ ekibin kendi işi.

Bir CRUD ekranını ya da bir API endpoint'ini Claude Code veya benzeri bir ajana birkaç dakikada yazdırmak artık sıradan iş. Kodun üretim maliyeti düştükçe, onu korumanın, refactor etmenin ve 'güzel tutmanın' göreli değeri de düşüyor. Bazı ekipler bir modülü yamamak yerine testleri sabit tutup modülü yeniden ürettiriyor.

Bu yaklaşım ancak bir koşulla güvenli: yeniden üretilen kodun neyi doğru yapması gerektiği koddan bağımsız bir yerde yazılı olmalı. Testler bunun bir kısmını taşır ama testler örnektir, kural değildir. 'Sipariş onaylandıktan sonra ürün kalemi eklenemez' bir invariant'tır; bunu üç test örneğiyle anlatabilirsiniz ama modelde tek cümle olarak durması gerekir. Anti-pattern: domain kurallarının tek kaynağının eski kod olması. Kodu attığınız an kuralları da atmış olursunuz.

DDD (Domain-Driven Design, alan güdümlü tasarım) açısından kalıcı katmanın minimum içeriği dört parça. Birincisi ubiquitous language (ortak dil): 'Müşteri', 'Hesap', 'Kullanıcı' aynı şey mi, değil mi? İkincisi aggregate'ler ve invariant'ları: hangi nesne grubu tek bir tutarlılık sınırı içinde değişir, hangi kural her zaman doğru kalmalı. Üçüncüsü domain event'leri: 'SiparişOnaylandı', 'ÖdemeReddedildi' gibi geçmiş zamanlı, iş açısından anlamlı olaylar. Dördüncüsü bounded context haritası: hangi kavram hangi bağlamda geçerli ve bağlamlar arası çeviri nerede yapılıyor.

Örnek: Bir abonelik SaaS'ında 'Plan' satış bağlamında fiyatı ve indirimi olan bir teklif, faturalama bağlamında dönemi ve vergi oranı olan bir kalemdir. Tek bir 'Plan' tablosuyla iki anlamı birleştirmek, ajanın her iki bağlamdaki spec'te farklı alanlar uydurmasına davetiye çıkarır. İki ayrı model ve aradaki çeviri katmanı daha fazla kod gibi görünür, ama ajan için çok daha net bir sınırdır.

Domain modeli bir Confluence sayfasında ya da bir duvar fotoğrafında kalırsa ajan için yok hükmündedir. Pratik hedef: repo içinde, sürümlenen, ajanın her görevde okuduğu bir dizin. Örneğin `domain/` altında bağlam başına bir glossary dosyası, aggregate başına kısa bir invariant listesi ve event kataloğu (event adı, alanları, hangi aggregate yayınlar).

Format tartışması ikincil; Markdown + tablo da olur, TypeScript tip tanımları + Zod şemaları da, hatta bir JSON Schema da. Önemli olan iki şey: spec şablonunuzun 'Bu özellik hangi aggregate'lere dokunuyor, hangi invariant'ları etkiliyor?' sorusunu zorunlu kılması ve CLAUDE.md / AGENTS.md gibi ajan talimat dosyalarının bu dizine açıkça işaret etmesi, ama modeli kendi içine kopyalamaması. Thoughtworks'ün Nisan 2026'da uyardığı gibi şişen talimat dosyalarında ortadaki kurallar gözden kaçıyor; talimat dosyası yalnızca hangi görevde hangi bağlam dosyasının okunacağını söylemeli (progressive context disclosure). Kural koyun: bir spec, glossary'de olmayan bir terimi kullanıyorsa ya terimi ekleyen bir model değişikliği PR'ı açılır ya da spec reddedilir.

Kalıcı model işe yarasın diye üç katman arasında bağ kurmak gerekiyor. Spec'teki her kabul kriteri bir invariant'a ya da bir domain event'ine referans vermeli; kodda o invariant'ı uygulayan yer (ör. aggregate metodundaki guard) ve onu doğrulayan test aynı kimliği taşımalı. Basit bir konvansiyon yeter: `INV-ORDER-03` gibi bir etiket model dosyasında tanımlanır, spec'te anılır, test adında geçer.

Bu bağ, 'kodu yeniden ürettirme' senaryosunu denetlenebilir yapar. Ajan modülü baştan yazdıktan sonra bir script, modeldeki her invariant kimliği için en az bir testin var olup olmadığını ve geçip geçmediğini kontrol eder. Eşik koymak mantıklı: kritik bağlamlarda (ödeme, faturalama) invariant kapsamı yüzde 100'ün altına düşerse merge engellenir. Anti-pattern: kabul kriterlerini UI davranışı olarak yazmak ('butona basınca hata göster'); bu kriterler model değiştiğinde hiçbir şeyi korumaz.

Kalıcı demek donmuş demek değil. Domain modeli de değişir, ama kodla aynı hızda değil ve aynı kişiler tarafından değil. Kod değişikliği dakikalar sürerken bir invariant değişikliği ürün, iş ve mühendislik arasında bir konuşma gerektirir. Bu yüzden model değişikliklerini ayrı bir PR türü olarak ele almak, ADR (Architecture Decision Record, mimari karar kaydı) benzeri kısa bir gerekçe istemek ve onayına domain sahibini dahil etmek mantıklı.

Ajan burada da yardımcı olabilir ama farklı bir rolde: yeni bir spec geldiğinde mevcut glossary ve invariant'larla çelişkileri listeleyen bir gözden geçirici olarak. Örneğin 'Kullanıcı birden fazla şirkete bağlı olabilir' diyen bir spec, 'Kullanıcı tek bir Tenant'a aittir' invariant'ıyla çakışır. Bu çakışmayı kod yazılmadan yakalamak, üç hafta sonra veri modelinde migration yazmaktan çok daha ucuz.