Domain Event'lerinin saklanmasi

[yarimadam]

DDD ve Mikroservis Mimari bolumunde kucuk bir kavram hatasina denk geldim.

Baslik: Domain Event’lerin Persistent(kalıcı) olarak saklanması

Burada domain eventlerinin event sourcing yontemi ile saklanmasindan bahsediliyor.

Domain event'leri business modelinin bir parcasidir. Bounded context icerisinde gerceklesen business olaylarini hem betimlemek hemde yaymak icin domain eventlerini kullanir.

ES eventleri esasen ilgili Aggregate'in mevcut hali ile alakalidir. Yerel event'lar olarakta gecer.

Dolayisi ile aslinda persist edilen domain eventlerinden ziyade ES event'leri olmalidir.

Domain eventleri ile ES eventlerinin bir noktada kesisir gibi olmasi aradaki ayrimin bazen mantiksal olarak fark edilememesine yol acabiliyor.

Ornegin bir Product product Aggregate'i olustugunda hem domain eventi hem ES eventi akla gelecektir.

Domain eventi muhattaplarin ihtiyaci olan minimum bilgiyi icermesi gerekirken ES eventi baslangic product halinin tamamini payload olarak icermek mecburiyetindedir.

Kucuk bit not olarak sunuda belirmek isterim: ES eventleri de bir event bus'a gonderilebilir. Bazi uygulamalar projeksiyonlari event bus araciligi ile tetikliyorlar.

Event sourcing'i bu kitapta aciklamak cok dogru olmadigindan belki ilgili paragraf tamamen kaldirilabilir.

[suadev]

Selam @yarimadam , Katkın için teşekkür ederim. Mesajını bir kaç kere okudum bir noktayı kaçırmış olmamak için, okurken "ES eventleri" ifaden dikkatimi çekti. Bu daha önce çok denk gelmediğim bir ifade şekli olduğundan belkide. Event sourcing bir pratik yani bir event i tanımlamak için kullanılması çok doğru gelmiyor bana. "ES Eventi" konseptini bilmiyor olabilrim bununla ilgili paylaşabileceğin bir link varsa okuyabilmem için çok sevinirim. Ek olarak, Domain enetleri aslında olayları "yaymak" için değil de daha çok aynı bounded context içerisinde varlık gösterir. "Yaymak" ile kastını anlıyorum sanırım ama orada Integration Event konsepti devreye giriyor.

[yarimadam]

Selamlar, biraz hizli yazdigim icin dogru terimleri kullanmamis olabilirim afedersin. Aslinda biraz daha vaktim oldugunda daha ozenli yazmaliydim. Ancak bu tarz Turkce kaynaklar pek olmadigi icin ve hemen issue acabilecegimi gorunce heyecanlandim ve yaziverdim. :)

ES eventlerinden kastim Aggregate Root'a (AR) etki eden eventler. Yani apply olan eventler. Bu eventler AR'nin state'ine etki ederler. Aslinda kisacasi ilgili AR'nin event stream'ine kaydedilen eventler.

Ornegin Product AR'sini olusturan yani ona initial state veren bir event dusunelim. Adi ProductWasCreated olsun. Payload icerisinde o Product'u olusturmak icin butun zorunlu tutulan data olmak zorunda.

Bu ProductWasCreated, event sourcing teknigi ile Product AR'sine apply edilen bir aggregate changed eventi.

Eger bir Product olusturulmus ise muhtemelen hem ayni bounded context (BC) icerisindeki diger AR'ler hem de diger BC'ler bu event ile ilgileniyor olabilir. Bu noktada artik domain eventleri kullanilmali. Cunku artik mesele bir event sourced AR'nin state'ine etki etmekten ziyade, hem domain icerisinde olan bir olayi hem betimlemek hem de diger ilgili BC'lerin ve AR'lerin haberdar olmasini saglamak.

Integration event aslinda domain event'in kendisi. Bazi projelerde cift event bus kullanildigindan oturu ayrica integration event diye betimlendigini dusunuyorum. Ornegin domain eventini MQ'ya gonderen ve ayni zamanda da local bir observer'e teslim eden iki farkli bus kullanilabiliyor. Bu durumda MQ'ya giden event integration event olarak algilanabilir ve isimlendirilebilir. Tabii neden local bir observer kullanip eventlerin senkronize bir sekilde consume edilmesi amaclanir? Orasi da sanirim gereksinim ve use-case'ler ile alakali. Ayni transaction icerisinde tutulmasi gerekiyorsa bu da bir use case olabilir. Bana gore cok gecerli sebepler yoksa integration event diye ayri bir konsepti projeye katmak, hic bir deger katmadan kompleksligi arttiracak bir aksiyon olur.

Ez cumle soyle sonuclandirabilirim:

Event sourced bir aggregate root'a apply edilecek eventler = aggregate changed tipi eventler
Domain icerisinde olan bir olayi betimlemek ve yaymak icin olusturulan eventler = domain event, integration event

Yukarida verdigim ProductWasCreated eventi her ne kadar hem domain eventi hem aggregate changed eventi gibi gozukse de, ikisi farkli eventler olmali cunku aggregate changed eventi (ProductWasCreated), Product AR'sini olusturan gerekli tum datayi icerisinde payload olarak bulundurmasi gerekirken, domain event (ProductWasCreated) belki sadece ProductID barindiracak.

Dolayisi ile:
aggregate changed ≠ domain event

Konuyu esas baglamina dondurecek olursam da yukarida acikladigim sebeplerden oturu domain eventleri persist edilen eventler olmamalidirlar.