**Ön Söz: Neden Bu Kitap?**

Bir an durup düşünelim. Sprint planlama toplantısındasınız. Product Owner, aciliyetle “yeni kampanya modülünü” anlatıyor. Analist, iş biriminden aldığı notları ekran görüntüleriyle dolu bir dokümana dökmüş. Geliştiriciler, “Bu butona basınca şu servis çağrılacak, veritabanına bu kayıt atılacak,” diye teknik detayları tartışıyor. Testçiler ise kabul kriterlerini netleştirmeye çalışıyor. Herkes çok meşgul, herkes çok "çevik". Peki, bu yoğunluğun ortasında şu soruyu hiç sordunuz mu: **“Biz gerçekten aynı şeyden mi bahsediyoruz?”**

Yıllardır yazılım geliştirme dünyasında Çevik (Agile) manifestolar ve Scrum çerçeveleri ile takımlarımızı daha hızlı, daha esnek hale getirmeye çalıştık. İki haftalık sprintlerde çalışan, her sabah "daily" yapan, her sprint sonunda bir "ürün parçası" çıkaran takımlar kurduk. Hızı yakaladık, ritüelleri ezberledik. Ancak bu süreçte bir şeyi gözden kaçırdık: **Anlamı.**

Projenin kalbinde yatan işin karmaşıklığını, inceliklerini ve dilini ıskaladık. Product Owner’lar yüzlerce maddelik bir "backlog"un altında ezilirken, geliştiriciler işin özünden kopuk, sadece veri taşıyan anlamsız nesnelerle dolu kod tabanları inşa ettiler. Analistler, iş birimi ile teknik ekip arasında yorucu birer "tercüman" haline geldiler. Sonuç mu? Sürekli değişen gereksinimler karşısında kolayca kırılan, bakımı zorlaşan, teknik borcun altında ezilen ve en kötüsü, asıl iş problemini çözmekten uzaklaşan yazılımlar... Namıdiğer **"özellik fabrikaları".**

Eğer bu satırları okurken başınızı sallıyorsanız, yalnız değilsiniz. Bu kitap, tam da bu "anlam" krizini yaşayan, "çevik olmanın" ötesine geçmek isteyen Scrum takımları için yazıldı. Sadece "nasıl" ürettiğimize değil, **"ne"** ürettiğimize ve bunu **"neden"** yaptığımıza odaklanmak isteyenler için.

Elinizdeki bu rehber, size sihirli bir formül ya da karmaşık bir metodoloji sunmuyor. Aksine, zaten bildiğiniz ve her gün içinde yaşadığınız işin (domain) kalbine inmek için bir harita vaat ediyor. Bu haritanın adı: **Domain-Driven Design (DDD).**

DDD, korkutucu teknik jargondan ibaret bir kavram değildir. DDD, her şeyden önce bir iletişim felsefesidir. Product Owner’dan geliştiriciye, analistten testçiye kadar tüm ekibin aynı dili konuşmasını sağlayan, işin karmaşıklığını kodun derinliklerine gömmek yerine onu modelleyerek yöneten bir yaklaşımdır.

Bu kitapta, klasik bir Scrum takımının yaşadığı tanıdık sorunlardan yola çıkacağız. Product Owner, analist, geliştirici, testçi ve takım lideri rollerinin her birinin bu yolculukta nasıl dönüşeceğini adım adım göreceğiz. Teknik bir reçete sunmak yerine, takımınızla birlikte işi keşfetmenizi sağlayacak **Event Storming** gibi güçlü atölye çalışmalarını nasıl uygulayacağınızı anlatacağız. Scrum ritüellerinizi DDD prensipleriyle nasıl daha anlamlı hale getirebileceğinizi göstereceğiz. Ve son olarak, dünyanın en büyük teknoloji şirketlerinin bu yaklaşımı kullanarak nasıl sürdürülebilir ve ölçeklenebilir sistemler inşa ettiğini gerçek örneklerle inceleyeceğiz.

Bu kitabın vaadi basit: Sizi ve takımınızı birer "kod yazıcı" olmaktan çıkarıp, iş problemini anlayan, çözen ve ona yön veren stratejik birer ortak haline getirmektir.

Eğer siz de artık "özellik fabrikasında" vardiyalı bir işçi gibi hissetmekten yorulduysanız ve yarattığınız yazılımın kalbine bir yolculuk yapmaya hazırsanız, doğru yerdesiniz.

Hadi başlayalım.

Elbette, "Yazılım Projelerindeki 'Anlam' Krizi" başlığını, kitabınızın ilk bölümünde okuyucunun kendi yaşadığı sorunları net bir şekilde görmesini sağlayacak şekilde detaylandıralım.

---

### **1. Yazılım Projelerindeki "Anlam" Krizi**

Modern yazılım geliştirme takımları, verimlilik ve hız konusunda çağ atladı. Scrum, Kanban gibi çevik metodolojiler sayesinde artık haftalar içinde fikirleri çalışan yazılımlara dönüştürebiliyoruz. Sürekli entegrasyon (CI/CD) boru hatlarımızla kodu dakikalar içinde canlı ortama taşıyabiliyoruz. Kısacası, birer **"özellik fabrikasına" (feature factory)** dönüştük. Sürekli üretiyoruz, sürekli teslimat yapıyoruz ve sürekli meşgulüz.

Ancak bu hız ve verimlilik sarhoşluğunun ortasında, projelerin ruhunu kemiren sinsi bir sorun yatıyor: **Anlam Krizi.**

Anlam krizi, bir takımın neyi, neden yaptığını derinlemesine anlamadan, sadece görev listesindeki maddeleri birer birer tüketerek ilerlemesi durumudur. Bu, aktivite ile değerin birbirine karıştırıldığı, "çok çalışmanın" "doğru işi yapmakla" eşdeğer sanıldığı bir yanılgıdır. Bu kriz, kendini farklı rollerde, farklı şekillerde gösterir.

#### **Krizin Yansımaları: Kim, Ne Yaşıyor?**

**1. "İstek Listesi" Tuzağındaki Product Owner:**

Product Owner'ın backlog'u, şirketin stratejik hedeflerini yansıtan öncelikli bir yol haritası olması gerekirken, çoğu zaman paydaşlardan gelen ve sonu gelmeyen bir istek listesine dönüşür. "Müşteri şunu istedi," "Satış ekibi bunu talep etti" gibi reaktif talepler arasında stratejik vizyon kaybolur. PO, takım ile iş birimleri arasında bir "sipariş memuruna" dönüşür ve sprint'lerin amacı, en çok bağıranın isteğini yetiştirmek haline gelir.

**2. "Tercüman" Rolündeki Analist:**

Analist, iş birimlerinin karmaşık, bazen çelişkili ve üstü kapalı ifadelerle anlattığı ihtiyaçları dinler. Sonra bu "soyut" bilgiyi, geliştiricinin anlayacağı "somut" teknik adımlara, kabul kriterlerine ve akış diyagramlarına "tercüme" etmeye çalışır. Bu çeviri sırasında anlam kayıpları kaçınılmazdır. İşin ruhu, özü ve "nedeni" yolda bir yerlerde buharlaşır; geriye sadece kurallar ve adımlar kalır.

**3. "Kod Makinesi" Haline Gelen Geliştirici:**

Geliştiriciye gelen görevler genellikle şöyledir: "Kullanıcı tablosuna 'doğum tarihi' kolonu ekle", "Sepete ekle butonuna basınca şu API'ı çağır." Geliştirici, bu görevin arkasındaki iş mantığını, yani bir müşterinin yaşının neden önemli olduğunu veya sepet sürecinin şirketin kârlılığını nasıl etkilediğini bilmek zorunda kalmaz. Sadece teknik görevi yapar. Kod, işin gerçekliğini yansıtan yaşayan bir model olmak yerine, birbiriyle zayıfça bağlantılı prosedürler ve veri yapılarından oluşan bir yığına dönüşür. Kod tabanında `SiparisManager`, `KullaniciHelper`, `UrunService` gibi isimler çoğalırken, "İndirim Uygula", "Siparişi Onayla" gibi işin dilini konuşan nesneler yok olur.

**4. "Senaryo Körlüğü" Yaşayan Testçi:**

Testçi, elindeki kabul kriterlerini bir kontrol listesi gibi takip eder. "Buton çalışıyor mu? Evet. Veri kaydediliyor mu? Evet." Ancak işin bütünsel senaryosunu ve uç durumlarını anlamadığı için, "Peki ya kullanıcı sepetine indirimli bir ürünü ekledikten sonra, indirimin süresi dolarsa ne olmalı?" gibi derin soruları soramaz. Hataları (bug) bulur, ancak bu hataların çoğu aslında analiz ve iletişim eksikliğinden kaynaklanan "anlam" hatalarıdır.

#### **Bu Krizin Kök Sebebi Nedir?**

Bu krizin temelinde **ortak bir dilin ve paylaşılan bir zihinsel modelin eksikliği** yatar.

* **İş Birimleri**, işlerini kendi jargonuyla anlatır.

* **Analistler ve Product Owner'lar**, bu jargonu basitleştirilmiş "user story" formatına döker.

* **Geliştiriciler**, bu hikayeleri kendi teknik dünyalarının diline (sınıflar, fonksiyonlar, veritabanı tabloları) çevirir.

Bu süreç, adeta bir "kulaktan kulağa" oyununa benzer. Oyunun sonunda ortaya çıkan mesaj, baştakiyle aynı değildir. Her çeviri adımında anlam aşınır, niyet kaybolur.

Sonuç olarak, teknik olarak doğru çalışan ama işin asıl problemini çözmeyen, esneklikten uzak, bakımı zor ve her yeni istekle birlikte daha da karmaşıklaşan bir yazılım ortaya çıkar. Takım sürekli "çalışır" ama asla "değer" üretemez. İşte bu, modern yazılım projelerinin sessiz ama en tehlikeli krizidir: **Anlam Krizi.**

Bu kitaptaki yolculuğumuz, bu krizi aşmak ve takımınıza kaybettiği anlamı geri kazandırmak üzerine olacak.