DDD, CQRS ve Event Sourcing: Karmaşık Sistemlerde Gerçek Dünya Deneyimleri

Medium'da oku
trendyoltechdomain-driven-designdddcqrsevent-sourcing
Not: Bu yazıda paylaşılan bilgiler, Trendyol Tech DDD Days — CQRS & Event Sourcing başlıklı etkinlikten alınan notlara dayanarak hazırlanmıştır.
Etkinlikte, Trendyol’dan Melek Bilgin Tamtürk, Sinan Baran ve Onur Destanoğlu’nun aktardığı gerçek proje deneyimlerinden ve sunum içeriklerinden faydalanılmıştır.

Giriş
Modern yazılım geliştirme süreçlerinde özellikle karmaşık domain yapıları ve dağıtık sistemlerle çalışırken, geleneksel mimari yaklaşımlar yetersiz kalabiliyor. Bu noktada Domain-Driven Design (DDD), CQRS ve Event Sourcing gibi kavramlar devreye giriyor. Trendyol’un gerçek dünyada bu mimarileri nasıl kullandığına dair edindikleri tecrübeler, avantajları ve karşılaştıkları zorluklar 27 Temmuz 2023 tarihli bu videoda paylaşılmış.

DDD (Domain-Driven Design) Nedir?

Eric Evans’ın 2003 yılında yayınladığı “Blue Book” ile hayatımıza giren DDD, karmaşık iş problemlerini çözmek için tasarlanan bir mimari yaklaşımdır. Temel amacı, yazılım ekipleri ile alan uzmanlarının (domain experts) aynı dili konuşmasını sağlamak ve doğru modelleme ile teknik çözümü domain bilgisiyle doğrudan beslemektir.

DDD’nin Sağladıkları

  • Ortak Dil (Ubiquitous Language): Teknik ve iş birimleri arasında köprü kurar.
  • Bağlam Sınırları (Bounded Context): Her ekibin ve sistemin kendi sınırlarını net çizer.
  • Taktiksel Yordamlar: Aggregate, Value Object, Domain Event gibi güçlü pattern’lerle modellemeyi destekler.

CQRS (Command Query Responsibility Segregation)

Nedir?

2010 yılında Greg Young tarafından popülerleştirilen CQRS, okuma ve yazma işlemlerini tamamen birbirinden ayıran bir mimari yaklaşımdır. Bu sayede:

  • Okuma (Query) ve yazma (Command) tarafları farklı modeller ve veri kaynakları kullanabilir.
  • Okuma tarafı optimize edilirken, yazma tarafı da kendi performans ve tutarlılık gereksinimlerine göre tasarlanabilir.

Avantajları

✅ Farklı teknoloji stack’leri kullanılabilir.
✅ Performans optimizasyonu kolaylaşır.
✅ Takım yapısı da bu mimariye göre ayrılabilir: bir ekip sadece okuma tarafını geliştirirken diğeri yazma tarafına odaklanır.

Dezavantajları

❌ Ekstra karmaşıklık.
❌ Okuma ve yazma modellerinin senkronizasyonu ciddi bir sorumluluk haline gelir.
❌ Eventual Consistency kabul edilmesi gerekir.

Event Sourcing

Nedir?

Event Sourcing, sistemdeki her değişikliğin bir event (olay) olarak kaydedilmesi prensibidir. Geleneksel sistemlerde sadece son durumu (current state) tutarken, Event Sourcing geçmişteki tüm değişiklikleri de saklar.

Faydaları

  • Denetlenebilirlik (Auditability): Tüm değişiklikler adım adım izlenebilir.
  • Geriye Dönme (Rewind): Sistemi istenen bir zamana geri almak mümkündür.
  • Gerçek Dünya Uyumlu: Gerçek dünyadaki süreçler de genellikle adım adım değişimlerden oluşur.

Zorluklar

  • Veri boyutu hızla büyür.
  • Replay (baştan oynatma) maliyetlidir.
  • Event şemalarının değişimi ciddi planlama gerektirir.

Gerçek Dünya Kullanımı: Trendyol Örneği

DDD & CQRS Uygulaması

Trendyol’da iade yönetim sistemi yeniden tasarlanırken, DDD ve CQRS prensipleri esas alındı. Bu süreçte:

  • Domain model oluşturuldu.
  • İş süreçleri (flows) netleştirildi.
  • CQRS ile okuma ve yazma operasyonları ayrıştırıldı.
  • Farklı veri kaynakları ve indeksleme teknolojileri (Kafka, ElasticSearch, PostgreSQL) kullanıldı.
  • Data akışları event-driven hale getirildi.

Neden CQRS?

  • Okuma yükü ile yazma yükü farklı olduğu için.
  • Farklı teknolojilerin güçlü yönlerinden faydalanabilmek adına.
  • Performans kritik olduğu için, okuma tarafında optimize indeksleme yapmak gerektiği için.

Event Sourcing’in Yeri

Her işlem bir event olarak kaydedildi. Bu event’ler:

  • Geçmişe dönük analizler.
  • Veri tutarlılığı kontrolleri.
  • Hukuki kayıt gereklilikleri. için kullanıldı.

Gerçek Zorluklar

  • Event şemalarının evrimi.
  • Toplam veri boyutunun yönetimi.
  • Eventual consistency ile kullanıcı deneyimini dengelemek.
  • Monitoring ve tracing süreçlerini güçlendirmek.

Dağıtık Sistemlerde Transaction Yönetimi

Two-Phase Commit (2PC)

  • Güçlü tutarlılık (Strong Consistency) sağlar.
  • Tüm katılımcılar koordinatör tarafından yönetilir.
  • Ancak performans ve ölçeklenebilirlik açısından mikroservis ortamlarında tercih edilmez.

Saga Pattern

  • Eventual consistency sağlar.
  • Tek bir global transaction yerine, bağımsız local transaction’lar zinciri oluşturulur.
  • Trendyol’da, özellikle sipariş ve iade süreçlerinde sıklıkla tercih edilen yaklaşımdır.
  • Choreography (event-driven) ve Orchestration (merkezi koordinatörlü) olarak ikiye ayrılır.

Sonuç

Trendyol’daki bu deneyim gösteriyor ki, her bir pattern veya mimari yaklaşımın yeri ve zamanı farklıdır. Ezbere “trend” yaklaşımları uygulamak yerine:

  • Önce domain’i anlamak.
  • İş gereksinimlerine göre uygun mimariyi seçmek.
  • Domain uzmanlarıyla sürekli iş birliği yapmak. başarıya giden en sağlıklı yoldur.

Özetle: Teknoloji bir araçtır, amaç doğru modeli ve doğru çözümü bulmaktır.

Kapanış

Trendyol’daki gerçek projelerden yola çıkarak DDD, CQRS ve Event Sourcing gibi kritik kavramlar bu yayında ele alınmış. Bu tür konularla ilgilenen herkesin, sadece teoriyi değil, pratik dünyada nasıl uygulandığını da göz önünde bulundurması öneriliyor.