Yapay zekanın belirsiz istekleri nasıl üretime hazır mimarilere dönüştürebileceğini görün: gereksinimleri çerçeveleme, varsayımları ortaya çıkarma, ödünleşmeleri haritalama ve tasarımları doğrulama.

"Prompt to architecture" (istekten mimariye) niyetinizi ("müşteri portalı oluştur") yapılabilir bir plana dönüştürme iş akışıdır: gereksinimler, varsayımlar, aday seçenekler, açık kararlar ve bileşenlerle veri akışlarının uçtan uca görünümü.
AI çıktısını test edip düzenleyebileceğiniz bir öneri olarak ele alın—nihai cevap olarak değil.
Üretime hazır olmak, tasarımın açıkça şunları kapsadığı anlamına gelir:
Diyagramlar yardımcı olur ama tanım onlar değildir.
1–2 cümleyle şunu belirtin:
Eğer istek gerçek bir kullanıcı veya aciliyet belirtmiyorsa, bunları sorun—aksi takdirde ödünleşmeleri sıralayamazsınız.
Ürün ve operasyon sinyallerini karıştırarak 3–5 ölçülebilir metrik seçin, örnekler:
"Metrik çoğalması"ndan kaçının: çok fazla öncelikleri belirsizleştirir; çok azı riski gizler.
Erken varsayımları ortaya çıkarın: trafik, veri kalitesi, kullanıcıların gecikmeye toleransı, on-call desteği. Sonra bunları ayırın:
Varsayımları açıkça belgeleyin (kim/onayladı/ ne zaman) ki sonra sorgulanıp düzeltilebilsin.
Erken aşamada karşılaştırılabilecek birkaç iyi seçenekle başlayın ve bir varsayılan seçin; ayrıca "ne zaman değiştirilir" koşullarını açıkça yazın, örneğin:
Amaç izlenebilir ödünleşmeler ve tek doğru cevabın olmadığı anlayışıdır.
Çekirdek domain nesnelerini (prompttaki isimler: User, Order, Ticket, Event) adlandırın ve her biri için:
Her bağımlılık (ödeme, mesajlaşma, LLM'ler, dahili API'ler) için başarısızlık davranışı tanımlayın:
Rate limitlerin olduğunu varsayın ve sıçramaların zincirleme arızalara yol açmaması için backpressure tasarlayın.
Her önemli seçim için kısa bir Architecture Decision Record (ADR) oluşturun:
AI'yi bir genç mimar gibi kullanın: hızlı seçenek üretebilir ama bağlama, kontrolleri ve yönlendirmeye ihtiyaç duyar. Yapmanız gerekenler:
Sonra "eleştir ve iyileştir" döngüleriyle devam edin: "Bu tasarımın kırılgan noktaları neler?" "Hangi gereksinimler karşılanmadı?" AI'nın doğrulayamacağı kesin detaylara karşı dikkatli olun.
text\nYou are helping design a system.\nContext: <1–3 paragraphs>\nConstraints: <bullets>\nNon-functional requirements: <latency, availability, security, cost>\nDeliverables:\n1) Assumptions + open questions\n2) 2–3 candidate architectures with pros/cons\n3) Key tradeoffs (what we gain/lose)\n4) Draft ADRs (decision, alternatives, rationale, risks)\n\n\n(Kod bloğu içeriğini olduğu gibi koruyun; çevirilmedi.)\n\n### "Eleştir ve iyileştir" döngüleriyle yineleyin\n\nİlk geçişin ardından hemen bir eleştiri isteyin:\n\n- "Bu tasarımda kırılgan veya riskli olan ne?"\n- "Hangi gereksinimler henüz karşılanmamış?"\n- "Yarım zamanımız olsaydı neyi basitleştirirdin?"\n\nBu, modelin erken tek bir yola kilitlenmesini engeller.\n\n### Yaygın başarısızlık modlarına dikkat edin\n\nAI kendinden emin konuşurken yanlış olabilir. Ortak sorunlar şunlardır:\n\n- Üretilmiş servisler/özellikler (halüsinasyon)—belgeler veya belirsizlik göstergesi isteyin\n- Kısıtları görmezden gelme (maliyet, veri yeri, ekip becerisi)—her tasarım seçimini bir gereksinime dayandırmasını isteyin\n- Aşırı mühendislik—"en küçük uygulanabilir mimari" seçeneğini zorlayın\n\nİsterseniz çıktıları hafif ADR'ler olarak yakalayıp repo yanında saklayabilirsiniz (bkz. blog/architecture-decision-records).\n\n## Mini yürüyüş: bulanık bir isteği hazır-inşa planına çevirmek\n\nBulanık istek: "Bir teslimat gecikecekse müşterileri uyaran bir sistem kur."\n\n### 1) Bunu gereksinimlere çevirin\n\nAI bunu somut ihtiyaçlara dönüştürmede yardımcı olur:\n\n- Kullanıcılar: operasyon ekibi, son müşteriler\n- Çekirdek akış: gönderi durumu al → gecikme riski tespit et → bildirim gönder → sonuçları takip et\n- Fonksiyonel olmayan: durum değişikliğinden sonra 2 dakika içinde uyarı, %99.9 kullanılabilirlik, anlaşmazlıklar için denetim kaydı\n\n### 2) Mimarini tersine çevirebilecek varsayımlar\n\nErken iki soru genellikle tasarımı tersine çevirir:\n\n- Varsayım A: durum güncellemeleri taşıyıcılardan gerçek zamanlı geliyor (webhook). Doğruysa, olay tabanlı işleme uygundur.\n- Varsayım B: güncellemeler her 15 dakikada bir polled ediliyor. Doğruysa, zamanlama, rate limit yönetimi gerekir ve "2 dakika" SLA'sı girişleri yeniden görüşmeden imkansız olabilir.\n\nBunları yazmak, yanlış şeyi hızla inşa etmeyi engeller.\n\n### 3) Seçenekler → ödünleşme çağrısı\n\nAI aday mimariler önerir:\n\n- Seçenek 1: Senkron API: carrier webhook → gecikme skorlayan servis → bildirim servisi
Daha sonra depolamayı kullanım biçimine göre (OLTP vs analitik) eşleştirin ve uçtan uca veri akışını çizin (ingestion → doğrulama/zenginleştirme → saklama/silme).
Ayrıca her ana varsayım için tetikleyiciye bağlı "çıkış rampaları" planlayın (ör. X RPS'yi aşarsak read replica ekle). ADR'leri sürümlü tutun ve arşivleyin; hafif bir şablon için blog/adr-template gibi bir iç referans kullanabilirsiniz.