Yazılım geliştirme kendi başına bir amaç değildir: 2025'e bir bakış

kapanış bildirimi

Bu makale İngilizce olarak da mevcuttur. Teknik yardımla tercüme edildi ve yayınlanmadan önce editoryal olarak gözden geçirildi.

Bir daha gösterme.

Yazılım geliştirme kendi başına bir amaç değildir, ancak her zaman temeldeki bir teknik detayı takip eder.

Bu ifade, Haberler Developer'daki blog yazılarımın her birinde var gibi görünüyor. Bu benim yol gösterici prensibim, inancım, pusulamdır. Ama 2025 benim için her zamankinden daha fazla anlam kazandığı yıl oldu.

Neden bu kadar çok yazılım projesi başarısız oluyor? Neden beklenenden daha pahalı hale geliyorlar, vaat edilenden daha uzun sürüyorlar ve umulandan daha az teslimat yapıyorlar? Tekrar tekrar gördüğüm cevap “Çünkü teknoloji başarısız oldu” değil. Çerçeveler oldukça iyiydi. Veritabanları oldukça hızlıdır. Bulut yeterince ölçeklenebilir. Hayır, teknik konular unutulduğu için projeler başarısız oluyor. Çünkü teknoloji başlı başına bir amaç haline geliyor. Çünkü gerçekte ne olduğunu merak etmek yerine veritabanı tabloları tasarlıyorsunuz.

Bu yıl buna karşı yazmaya çalıştım. Ve sadece bu değil.

EventSourcingDB: Tezin sonucu

Bu yılın mayıs ayında, özellikle olay kaynağı bulma için tasarlanmış bir veritabanı olan EventSourcingDB'yi piyasaya sürdük. Başka bir NoSQL veritabanı, başka bir “aracın sonu” aracı değil, bir inancın teknik sonucu.

Etkinlik kaynağı sizi profesyonellik hakkında düşünmeye zorlar. Durumlar kaydedilmez, daha ziyade teknik olaylardır. “Müşterinin Y adresi var” değil, “Müşteri 15 Mart'ta aşağıdaki adrese taşındı”. Sadece küçük bir fark gibi görünüyor ama perspektifte temel bir değişim. Teknoloji tahakküme hizmet eder, tam tersi değil.

EventSourcingDB'nin şu anda 10.000'den fazla Docker indirmesine sahip olmasından mutluyum. Ancak giderek daha fazla geliştiricinin teknik yönleri ciddiye alan böyle bir araç aradığından daha da mutluyum.

Ortak konu: yılın en önemli makaleleri

2025'te Haberler Developer'da 40'tan fazla blog yazısı yayınladım. Etkinlik kaynağı kullanımı, mimari, yapay zeka, çeviklik ve bunun derinlikleri hakkında bilgi edinin. Ama geriye dönüp baktığımda, bunlardan yedisinin asıl ilgilendiğim şeyin merkezinde yer aldığını görüyorum. Birlikte bir hikaye anlatıyorlar: Yazılım geliştirmenin neden farklı şekilde düşünülmesi gerektiğinin hikayesi.

Sorunu görünür hale getirin

Bir masalla başlamak istiyorum. “CRUD neden masallara ve iş dünyasına uygun değildir?” adlı blog yazımda karmaşık bir konuyu basit bir metaforla erişilebilir hale getirmeye çalıştım: Kurt büyükanneyi ortadan kaldırmadı, onu yedi.

CRUD (Oluştur, Oku, Güncelle, Sil), çoğu uygulamanın standart sözlüğüdür. Ancak bu teknik bir sözcük dağarcığıdır, profesyonel bir sözcük dağarcığı değil. Gerçekte ne olduğunu gizler. İş süreçlerini veritabanı işlemlerine indirger. Ve sistemleri geçmişin kaybolduğu kara deliklere dönüştürüyor.

Peri masalının sinirlere dokunduğu belliydi. Belki de her geliştirici bir sistemle karşılaşmış ve kendisine “Bu veri seti aslında nasıl bu duruma geldi?” diye sormuştur.

Kavramsal temeller

Sorun CRUD ise çözümü nedir? Bu soruyu iki makalede yanıtladım: “Event Sourcing: geliştirmenin en iyi yolu?” ve “Modern, esnek ve ölçeklenebilir bir uygulama mimarisinin temeli olarak CQRS.”

Olay kaynağı, durumu değil, bu duruma yol açan olayları depolamak anlamına gelir. CQRS ayrı okuma ve yazma anlamına gelir çünkü her ikisinin de farklı gereksinimleri vardır. Birlikte, teknikliği ciddiye alan sistemlerin yapı taşlarını oluştururlar. Ne olduğunu anlayabileceğiniz, eski verilerle ilgili yeni sorular sorabileceğiniz sistemler.

Derinlemesine analiz

Kavramlar bir şeydir, uygulama başka bir şeydir. Bu yüzden yaz boyunca yedi bölümlük bir dizi yazdım: “Olay Odaklı.” Klasik mimarinin sınırlamalarından olaya dayalı sistemlerin yapı taşlarına, şehir kütüphanesi örneğini kullanarak pratik uygulamaya kadar.

Bu yıl konuyla ilgili en kapsamlı çalışmamdı. Olay odaklı mimarinin akademik bir kavram değil, alanın dilini konuşan bir yazılım geliştirmenin pratik bir yolu olduğunu göstermek benim için önemliydi.

Profesyonelliğin hizmetinde derinlemesine teknik analiz

Olay kaynağından bahseden herkesin aynı zamanda güvenden de bahsetmesi gerekir. Belirli bir olayın belirli bir zamanda gerçekleştiğini nasıl kanıtlayabilirim? Tüm verilerimi ifşa etmek zorunda kalmadan izlenebilirliği nasıl sağlayabilirim?

“Merkle Ağaçları: Veri Bütünlüğünü Kriptografik Olarak Kanıtlamak” başlıklı yazımda bu soruların nasıl zarif bir şekilde yanıtlanabileceğini gösterdim. Merkle ağaçları yeni bir buluş değil. Git'teyim, blockchainlerdeyim, sertifika şeffaflığındayım. Ancak olay kaynağı bulmayla birlikte tüm güçlerini geliştirirler: izlenebilirliği yalnızca mümkün kılmakla kalmaz, aynı zamanda kanıtlanabilir hale getirirler.

Bu teknik bir hile değil. Bu, uyumluluk, denetimler ve GDPR için geçerlidir. Teknoloji gerçek ihtiyaçların hizmetinde.

Kutsal inekleri sorgulayın

Bu serideki son makale en yeni ve belki de en tartışmalı olanıdır: “DDD'nin DDD'ye uygulanması artık Etki Alanına Dayalı Tasarım bırakmaz.”

Etki alanı odaklı tasarım benim topluluğumda bir nevi kutsal bir inektir. Ve DDD'nin temel fikirlerini gerçekten takdir ediyorum. Ama aynı zamanda DDD'nin kendisinin nasıl serbest mesleğe dönüştüğüne de bakıyorum. Ekiplerin, bir konunun uzmanıyla konuşmadan sınırlı bağlamları nasıl tanımladıkları. Değer kümeleri ve nesnelerin, alana hizmet etmek yerine nasıl kendi başlarına amaç haline geldikleri.

Bu Eric Evans'a ya da DDD'ye fikir olarak bir eleştiri değil. Bu, bir topluluk olarak bazen sonuçlardan ziyade yöntemlere nasıl öncelik verdiğimizin bir eleştirisidir. Ve bu, en sevdiğimiz araçları bile eleştirel bir biçimde sorgulamamız için bir çağrıdır.

Ne kadar yazarsam yazayım sonuçta bu konuları hayata geçiren topluluktur. Ve 2025 bana inançlarımda yalnız olmadığımı gösterdi.

Ekim ayında meslektaşım Rendani ve ben, EventSourcingDB'nin sponsorları ve katılımcıları olarak ilk kez Berlin'deki KanDDDinsky'deydik. Etki alanı odaklı tasarım, etkinlik kaynağı oluşturma ve iyi düşünülmüş yazılım mimarisine olan tutkumuzu paylaşan 250 ila 300 kişi. Oradaki konuşmalar bana konunun ivme kazandığını gösterdi. Olay kaynak kullanımı ve CQRS artık küçük bir grup meraklı tarafından izole köşelerde uygulanan niş ilgi alanları değil.

Digital Frontiers'ın, yerel EventSourcingDB entegrasyonuna sahip JVM için bir CQRS ve olay kaynak bulma çerçevesi olan OpenCQRS 1.0'ı piyasaya sürmesinden özellikle memnun kaldım. Bir ekosistem yaratılıyor. Diğerleri temel üzerine inşa eder. Bu, bir projeye koyduğunuz çalışmanın en iyi doğrulanmasıdır.

Ve tabii ki yorum yapan, tartışan, karşı çıkan okuyuculara da teşekkür etmek istiyorum. Özellikle tartışmalı yazılar konunun ilerlediğini bana gösterdi. Çelişki sorun değil, kayıtsızlık olur.

Perspektifler: Profesyonellik, mimari ve yapay zeka

2026 yılına baktığımda her şeyi gölgede bırakacak bir konu görüyorum: yapay zeka. Ama sıklıkla tartışıldığı şekilde değil.

“Yapay zeka için mükemmel bir temel olarak olay kaynağı oluşturma” adlı blog yazımda, yapay zeka tartışmasının çoğunlukla modellerle başladığını savundum. Hangi LLM en iyisidir? GPT mi yoksa Claude mu? Ama bu yanlış soru. Doğru soru şudur: “Hangi verilere sahibim?”

Yüksek kaliteli verilere sahip ortalama bir model, düşük kaliteli verilerle eğitilmiş herhangi bir üst modeli yenebilir. Ve çoğu şirketin verileri kalitesizdir çünkü yalnızca mevcut durumu bilen CRUD sistemlerinde bulunur. Geçmiş mi? Üzerine yazıldı. Bağlam mı? Kayıp. Nedensellik? Yeniden inşa edilemez.

Olay kaynağı bunu değiştirir. Bağlam açısından zengin, anlaşılır veriler sağlar. Sadece “Nedir?” sorusuna değil, “Nasıl oldu?” sorusuna da cevap veriyor. Yapay zekânın ihtiyacı olan da tam olarak budur.

Aynı zamanda yazılım geliştirmede değer yaratma da değişiyor. “Yapay Zeka, Geliştiricileri Değiştirilebilir Hale Getiriyor, Ancak İyi Mimarlar Değil” başlıklı yazımda bunun ne anlama geldiğini açıklamıştım: Kodlama bir meta haline gelir. Geriye alan bilgisi, mimari ve modelleme kalıyor. Bu bizim mesleğimiz için bir felaket değil, profesyonelliği ciddiye alan herkes için bir fırsattır.

Mimarlık, uzmanlık ve yapay zekanın birleşimi gelecekte giderek daha önemli hale gelecektir. İyi veri üreten sistemlerin nasıl oluşturulacağını anlayan, yapay zekanın nasıl mantıklı bir şekilde kullanılacağını anlayan ve aynı zamanda geliştirdikleri sektörü anlayanlar talep görecek. Şu anda 2026 için bir web semineri serisi üzerinde tam olarak bu arayüz üzerinde çalışıyorum: tech: lounge 360°. Yapay zekaya kapılmak istemeyen, onu anlamak ve kullanmak isteyen herkes için.

Nihayet

Yazılım geliştirme başlı başına bir amaç değildir. Bu makalenin başındaki yol gösterici prensibim buydu ve bu yılın sonunda da yol gösterici prensibim olacak.

Benim için 2025 yılı bu ifadenin şekillendiği yıldı: EventSourcingDB'de, 40'tan fazla blog gönderisinde, konferans konuşmalarında, müşteri çalışmalarında. Yoğun, verimli bir yıl oldu ve bu yolculukta bana eşlik eden herkese minnettarım.

Sana yıllar arasında zaman diliyorum. Çözmek istediğiniz teknik sorunun gerçekte ne olduğunu düşünmenin zamanı geldi. Artık durup kendinize, çalıştığınız teknolojinin profesyonel amaçlara mı hizmet ettiğini yoksa başlı başına bir amaç haline mi geldiğini sormanın zamanı geldi.

Ve sonra teknolojinin olması gerektiği gibi, bu profesyonelliğin hizmetinde bir araç olarak geri döneceği bir 2026 yılı.

Mutlu Noeller, huzurlu ve dinlendirici bir tatil ve yeni yıla güzel bir başlangıç.

(Ben)