Bu bölümde ikinci kez konuğum olan Zikriye Ürkmez, Türkçe kaynaklarda Domain-Driven Design üzerine en çok yazan isimlerden biri. DDD’nin aslında ne olduğunu ve neden bir araçtan çok bir felsefe olduğunu konuşarak başlıyoruz. Sonra yapay zeka çağında problemi anlamanın neden her zamankinden daha değerli hale geldiğine bakıyoruz: AI teknik tasarımı yapabilirken stratejik tasarımda neden insana ihtiyaç duyuluyor, AI bizi farkında olmadan nasıl ikna ediyor? Ekipte DDD’ye geçerken yaşanan zihniyet dönüşümünü, “DDD hız kaybettirir mi?” sorusunu ve ajanlarla çalışırken bounded context ile ortak dilin neden kritik olduğunu tartışıyoruz. Son olarak DDD trilemmasına ve mevcut bir projede işe nereden başlanacağına değiniyoruz. Kod yazmak giderek kolaylaşırken problemi anlamak neden hâlâ asıl iş, bunu birlikte konuşuyoruz.

Öne Çıkan Başlıklar

  • Domain-Driven Design Nedir?: DDD’nin gerçek hayattaki iş problemini modelleme ve iş kurallarını koda anlaşılır biçimde aktarma yaklaşımı olarak ele alınması, asıl değerinin teknik tasarımdan çok stratejik tasarımda olduğu vurgulanmıştır.
  • Problemi Anlamak ve DDD Yazı Serisi: Geliştiricilerin çözüme odaklanıp problemi anlamakta zayıf kaldığı, mülakatlarda ve yeni katılan ekip üyelerinde görülen bu eksikliğin DDD yazı serisinin çıkış noktası olduğu anlatılmıştır.
  • Yapay Zeka Çağında DDD: AI’ın teknik tasarımı yapabildiği ancak domain uzmanıyla konuşup problem uzayında zaman geçirmeyi gerektiren stratejik tasarımı yapamadığı tartışılmıştır. AI ile öğrenme yanılgısı ve modelin verdiği kararları kendi kararımız gibi benimseme tehlikesi ele alınmıştır.
  • Ekipte Zihniyet Dönüşümü ve Hız Baskısı: Geliştiricilerin hemen koda geçme isteği, AI’ın işin dopamin veren kısmını elimizden alması ve DDD’nin yalnızca karmaşık, hataya toleransı düşük alanlarda uygulanmasının hız kaybı yaratmadığı konuşulmuştur. Harness engineering, software factory ve AI ajanları için bounded context ile ortak dilin (ubiquitous language) önemine değinilmiştir.
  • Stratejik ve Teknik Tasarım Farkı: Problem uzayı ile çözüm uzayı, bounded context sınırlarının çizilmesi ve domain’in dış bağımlılıklardan korunması üzerine konuşulmuştur.
  • DDD Trilemması ve Nereden Başlamalı?: Domain saflığı, performans ve bütünlüğün aynı anda sağlanamaması, CQRS ve bilinçli tercihler ele alınmıştır. Mevcut bir projede DDD’ye başlamak için anemik modelden zengin (rich) domain modeline geçiş ve iş kurallarını tek bir yerde toplamak önerilmiştir.

Konuk:

Zikriye Ürkmez: https://www.linkedin.com/in/zikriye-urkmez-cengiz/

Zikriye’nin DDD yazı serisi: https://codewarts.substack.com/p/ddd-1-tasarm-ve-yazlmn-sonunda-bulustugu

Zikriye’yi takip edin: https://codewarts.substack.com/

Bana ulaşmak için;
enderin.co
https://x.com/enderinco_pod
https://instagram.com/enderinco_pod