event sourcing

• verileri şu anki durumu yansıtan bir tabloya koymaktansa olup biteni not alıp şu anki durumu bilmek istediğinizde olup bitene bakıp hesaplama kafası design pattern.
  
  şurada güzelce anlatılmış: https://www.youtube.com/watch?v=jhgkashoyns
• tane tane anlatılan bir başka doküman: https://ookami86.github.io/…t-sourcing-in-practice/
• mesela,
  
  bir ürünün stokta kaç tane olduğunu hesaplamak için tüm geçmiş stok hareketlerini toplama işlemidir.
  
  bu durumda veri tabanında tutulan veri miktarını azaltırken toplam stok miktarı sorgusunun hızını düşüren bir uygulamadır. günde binlerce satılan ürünler için stok miktarını görmek kabus haline gelebilir.karşılığında stok miktarları ve stok hareketleri için iki ayrı tabloyu idare etmek zorunda kalmazsınız, olay tek tabloda biter. böylece entegrasyon problemlerinin de önüne geçilir.
  
  event sourcing kötü bir uygulama değildir, doğru yerde kullanıldığında çiçek gibidir.
• (bkz: olay kaynaklama)
• nihai state'i tutmak yerine, eylemlerin kendisini tutmak ve ihtiyac halinde sirayla uzerlerinden gecmek suretiyle nihai state'i yeniden olusturma olayidir temelinde.
  
  ornek olarak bir hesabin bakiyesini tutmak yerine bakiyenin o duruma gelmesine neden olan transaksiyonlari (giris/cikis vs.) saklamak ve zamani geldiginde bu islemleri bastan sona (worst case) okuyarak bakiyeyi elde etmek verilebilir. boylece bir ana rollback etmek, islem takibi, analizi ve audit log olaylari vs. kolaylasir.