Olay Kaynağını Belirleme düzeni

Etki alanındaki verilerin yalnızca geçerli durumunu depolamak yerine bu verilerin üzerinde gerçekleştirilen tüm eylem serisini kaydetmek için bir salt ekleme deposu kullanın. Depo bir kayıt sistemi işlevi görür ve etki alanı nesnelerini gerçekleştirmek için kullanılabilir. Bu, veri modelini ve iş etki alanını eşitleme gereğini ortadan kaldırarak karmaşık etki alanlarındaki görevleri basitleştirebilirken, performansı, ölçeklenebilirliği ve yanıt sürelerini de geliştirir. Ayrıca işlem verilerinde tutarlılık sağlayabilir ve telafi eylemlerine olanak tanıyacak tam denetim kayıtlarını ve geçmişini koruyabilir.

Bağlam ve sorun

Uygulamaların çoğu verilerle çalışır ve uygulama için tipik yaklaşım kullanıcılar veriler üzerinde çalışırken verileri güncelleştirerek geçerli durumu korumaktır. Örneğin, geleneksel oluşturma, okuma, güncelleştirme ve silme (CRUD) modelinde tipik bir veri süreci, mağazadan verileri okumak, üzerinde bazı değişiklikler yapmak ve verilerin geçerli durumunu yeni değerlerle güncelleştirmek (genellikle verileri kilitleyen işlemler kullanarak).

CRUD yaklaşımının bazı sınırlamaları vardır:

  • CRUD sistemleri güncelleştirme işlemlerini doğrudan veri deposunda yapar; bu da işlem ek yükü getirerek performansı yavaşlatabilir, yanıt hızını düşürebilir ve ölçeklenebilirliği sınırlayabilir.

  • Birçok eş zamanlı kullanıcısı olan işbirliğine dayalı bir etki alanında, veri güncelleştirme çakışmalarının olma olasılığı daha yüksektir çünkü güncelleştirme işlemleri tek bir veri öğesinde gerçekleşir.

  • Her işlemin ayrıntılarını ayrı günlüğe kaydeden ek bir denetim mekanizması olmadığı sürece geçmiş kaybolur.

Çözüm

Olay Kaynağını Belirleme düzeni, her biri salt ekleme deposuna kaydedilmiş bir olay dizisinin yönlendirdiği veriler üzerindeki işlemleri işlemek için bir yaklaşım tanımlar. Uygulama kodu olay deposunda kalıcı olarak saklanan veriler üzerinde gerçekleşen her eylemi kesin olarak açıklayan bir dizi olay gönderir. Her olay, verilerdeki bir dizi değişikliği temsil eder (örneğin, AddedItemToOrder).

Olaylar, verilerin geçerli durumu hakkında bir kayıt sistemi (yetkili veri kaynağı) işlevi gören olay deposunda kalıcı olarak saklanır. Olay deposu müşterilerin bu olaylarla ilgili bildirim alabilmesi ve gerektiğinde bunları işleyebilmesi için normalde bu olayları yayımlar. Örneğin müşteriler, olaylardaki işlemleri başka sistemlere uygulayan görevler başlatabilir veya işlemi tamamlamak için gereken diğer ilişkili eylemlerden birini gerçekleştirebilir. Olayları oluşturan uygulama kodunun olaylara abone olan sistemlerden ayrıldığına dikkat edin.

Olay deposu tarafından yayımlanan olaylar tipik olarak uygulamadaki eylemler varlıkları değiştirirken bu varlıkların gerçekleştirilmiş görünümlerini korumak amacıyla ve dış sistemlerle tümleştirme için kullanılır. Örneğin bir sistem, kullanıcı arabiriminin bölümlerini doldurmak için kullanılan tüm müşteri siparişlerinin bir gerçekleştirilmiş görünümünü koruyabilir. Uygulama yeni siparişler eklerken, siparişteki öğeleri ekler veya kaldırırken ve teslimat bilgilerini eklerken, bu değişiklikleri açıklayan olaylar gerçekleştirilmiş görünümü güncelleştirmek için işlenebilir ve kullanılabilir.

Buna ek olarak, herhangi bir noktada uygulamaların olayların geçmişini okuması ve varlıkla ilgili tüm olayları kayıttan yürüterek ve kullanarak varlığın geçerli durumunu gerçekleştirmek için kullanması mümkündür. Bu, istek işlenirken talep üzerine etki alanı nesnesini gerçekleştirmek için veya sunu katmanını desteklemek amacıyla varlık durumunun bir gerçekleştirilmiş görünüm olarak depolanabildiği zamanlanmış bir görev aracılığıyla yapılabilir.

Şekilde bu düzen genel çizgileriyle gösterilir; gerçekleştirilmiş görünüm oluşturma, olayları dış uygulamalar ve sistemlerle tümleştirme ve belirli varlıkların geçerli durumunun izdüşümlerini oluşturmak üzere olayları yeniden yürütme gibi, olay akışını kullanmaya yönelik bazı seçenekler de eklenmiştir.

Olay Kaynağını Belireme düzenine genel bakış ve örnek

Olay Kaynağını Belirleme düzeni aşağıdaki avantajları sağlar:

  • Olaylar sabittir ve salt ekleme işlemi kullanılarak depolanabilir. Bir olayı başlatan kullanıcı arabirimi, iş akışı veya işlem devam edebilir ve olayları işleyen görevler arka planda çalıştırılabilir. Bu, işlemler yapılırken çekişme olmaması gerçeğiyle birleştirildiğinde, özellikle de sunu düzeyi veya kullanıcı arabirimi için uygulamaların performansını ve ölçeklenebilirliğini çok büyük ölçüde geliştirebilir.

  • Olaylar, olay tarafından temsil edilen eylemi açıklamak için gereken ilişkili verilerle birlikte, gerçekleşen bazı eylemleri açıklayan basit nesnelerdir. Olaylar veri deposunu doğrudan güncelleştirmez. Bunlar yalnızca uygun zamanda işlenmek üzere kaydedilir. Bu da uygulamayı ve yönetimi basitleştirebilir.

  • Olaylar normalde bir etki alanı uzmanı için anlamlıdır; oysa nesne-ilişkisel empedans uyuşmazlığı karmaşık veritabanı tablolarının anlaşılmasını güçleştirebilir. Tablolar, gerçekleşen olayları değil sistemin geçerli durumunu temsil eden yapay yapılardır.

  • Olay kaynağını belirleme eş zamanlı güncelleştirmelerin çakışmalara neden olmasını önlemeye yardım edebilir çünkü nesneleri doğrudan veri deposunda güncelleştirme gereğini ortadan kaldırır. Bununla birlikte, etki alanı modelinin yine de kendini tutarsız bir duruma yol açacak isteklerden koruyabileceği şekilde tasarlanması gerekir.

  • Olayların salt ekleme depolaması veri deposunda gerçekleştirilen eylemleri izlemek, olayları herhangi bir anda yeniden yürüterek geçerli durumu gerçekleştirilmiş görünümler veya izdüşümler olarak yeniden oluşturmak, ayrıca test ve hata ayıklama sistemine yardımcı olmak için kullanılabilecek bir denetim kaydı sağlar. Buna ek olarak, değişiklikleri iptal etmek için telafi olayları kullanma gereksinimi tersine çevrilmiş değişiklik geçmişi sağlar. Model yalnızca geçerli durumu depoladığında böyle bir şey olmaz. Olay listesi uygulama performansını analiz etmek ve kullanıcı davranışı eğilimlerini algılamak veya işle ilgili diğer yararlı bilgileri elde etmek için de kullanılabilir.

  • Olay deposu olayları oluşturur ve görevler de bu olaylara yanıt olarak işlemleri gerçekleştirir. Görevlerin bu şekilde olaylardan ayrılması esneklik ve genişletilebilirlik sağlar. Görevler olay türü ve olay verileri hakkında bilgi sahibidir ama olayı tetiklemiş olan işlem hakkında bilgi sahibi değildir. Buna ek olarak, her olayı birden çok görev işleyebilir. Bu, yalnızca olay deposu tarafından oluşturulan yeni olayları dinleyen diğer hizmetler ve sistemlerle kolay tümleştirmeye olanak sağlar. Öte yandan, olay kaynağını belirleme olayları çok düşük düzeyli olabilir ve bunun yerine belirli tümleştirme olayları oluşturmak gerekebilir.

Olay kaynağını belirleme yaygın olarak CQRS düzeniyle birlikte kullanılarak olaylara karşılık olarak veri yönetim görevleri gerçekleştirilir ve depolanan olaylardan gerçekleştirilmiş görünümler oluşturulur.

Sorunlar ve dikkat edilmesi gerekenler

Bu düzenin nasıl uygulanacağına karar verirken aşağıdaki noktaları göz önünde bulundurun:

Sistem ancak olaylar yeniden yürütülerek gerçekleştirilmiş görünümler veya verilerin izdüşümleri oluşturulduğunda son tutarlılığa kavuşur. Uygulamanın istekleri işlemenin sonucu olarak olayları olay deposuna eklemesiyle olayların yayımlanması ve olayların tüketicilerinin bunları işlemesi arasında bir gecikme süresi vardır. Bu süre içinde, olay deposuna varlıklarda yapılan başka değişikliklerin açıklandığı yeni olaylar gelmiş olabilir.

Not

Son tutarlılık hakkında bilgi için Veri Tutarlılığı Temel Bilgileri'ne bakın.

Olay deposu kalıcı bilgi deposudur ve dolayısıyla olay verilerinin hiçbir zaman güncelleştirilmemesi gerekir. Bir değişikliği geri almak için varlığı güncelleştirmenin tek yolu, olay deposuna bir telafi olayı eklemektir. Kalıcı olayların verilerini değil de biçimini değiştirmek gerekiyorsa (belki bir geçiş sırasında), depodaki mevcut olayları yeni sürümle birleştirmek zor olabilir. Yeni biçimle uyumlu olabilmeleri için, yapılan değişiklikleri tüm olaylarda yinelemek gerekebilir veya yeni biçimi kullanan yeni olaylar eklenebilir. Hem eski hem de yeni olay biçimlerini korumak için olay şemasının her sürümünde bir sürüm damgası kullanmayı göz önünde bulundurabilirsiniz.

Olay deposunda çok iş parçacıklı uygulamalar ve uygulamaların birden çok örneği olayları depoluyor olabilir. Olay deposundaki olayların tutarlılığı, aynı belirli bir varlığı etkileyen olayların sırası gibi yaşamsal önem taşır (varlıkta gerçekleşen değişikliklerin sırası varlığın geçerli durumunu etkiler). Her olaya bir zaman damgası eklemek sorunları önlemeye yardımcı olabilir. Bir diğer yaygın yöntem de, bir isteğin sonucu olan her olaya artımlı bir tanımlayıcı eklemektir. İki eylem aynı varlık için aynı anda olaylar eklemeye çalışırsa, olay deposu mevcut varlık tanımlayıcısı ve olay tanımlayıcısıyla eşleşen olayı reddedebilir.

Bilgileri almak üzere olayları okumak için standart bir yaklaşım veya SQL sorguları gibi mekanizmalar yoktur. Ayıklanabilecek tek veri, ölçüt olarak olay tanımlayıcısının kullanıldığı bir olay akışıdır. Olay kimliği normalde tek tek varlıklarla eşlenir. Varlığın geçerli durumu, yalnızca bu varlığın özgün durumu üzerinde varlıkla ilgili tüm olaylar yeniden yürütülerek saptanabilir.

Her olay akışının uzunluğu, sistemin yönetilmesini ve güncelleştirilmesini etkiler. Akışlar büyükse, belirtilen sayıda olay gibi belirli aralıklarda anlık görüntüler oluşturmayı göz önünde bulundurun. Varlığın geçerli durumu anlık görüntüden ve bu noktadan sonra gerçekleşen tüm olayların yeniden yürütülmesiyle elde edilebilir. Verilerin anlık görüntülerini oluşturma hakkında daha fazla bilgi için bkz. birincil-alt anlık görüntü çoğaltma.

Olay kaynağını belirleme verilerde yapılan güncelleştirmelerin çakışma olasılığını en aza indirse de, yine de uygulamanın son tutarlılıktan ve işlem eksikliğinden kaynaklanan tutarsızlıklarla başa çıkabilmesi gerekir. Örneğin, bir öğe için sipariş verildiği sırada veri deposuna stok envanterinde düşüşü gösteren bir olay gelebilir; sonuçta müşteriyi bilgilendirerek veya bir sipariş açığı oluşturarak iki işlem arasında mutabakat sağlamak gerekir.

Olay yayını en az bir kezolabilir ve bu nedenle olayların tüketicilerinin ıdempotent olması gerekir. Olay birden çok kez işlendiyse olayda açıklanan güncelleştirmeyi yeniden uygulamaları gerekir. Örneğin, bir tüketicinin birden çok örneği, verilen toplam sipariş sayısı gibi bir varlığın özelliğini koruursa ve topladıysanız, sipariş verilen bir olay gerçekleştiğinde toplamın arttırılarak yalnızca bir tane başarılı olmalıdır. Bu olay kaynağını belirlemenin başlıca özelliklerinden biri değilse de, normal bir uygulama kararıdır.

Bu düzenin kullanılacağı durumlar

Aşağıdaki senaryolarda bu düzeni kullanın:

  • Verilerdeki hedefi, amacı veya nedeni yakalamak istediğinizde. Örneğin, bir müşteri varlığındaki değişiklikler, taşınan giriş, kapalı hesapveya öldügibi belirli bir olay türü serisi olarak yakalanabilirler.

  • Verilerde çakışan güncelleştirmeler yapılmasını en aza indirmek veya tamamen önlemek çok önemli olduğunda.

  • Gerçekleşen olayları kaydetmek ve sistemin durumunu geri yüklemek üzere bunları yeniden yürütebilmek istediğinizde, değişiklileri geri alın veya bir geçmiş veya denetim günlüğü tutun. Örneğin, birden çok adımdan oluşan görevlerde, güncelleştirmeleri geri çevirme eylemlerini yürütmeniz ve ardından verileri yeniden tutarlı bir duruma getirmek için bazı adımları yeniden yürütmeniz gerekebilir.

  • Uygulamanın işlemlerinde olaylar doğal bir özellik olarak kullanıldığında ve biraz ek geliştirme ve gerçekleştirme çalışması gerektirdiğinde.

  • Bu eylemleri uygulaması gereken görevlerden veri girişi yapma veya güncelleştirme işlemini ayırmanız gerektiğinde. Bu, UI performansını geliştirmek veya olaylar gerçekleştiğinde eylem yapan diğer dinleyicilere eylemleri dağıtmak için olabilir. Örneğin, bordro sistemini gider bildirimi web sitesiyle tümleştirilebilir; böylece web sitesinde yapılan veri güncelleştirmelerine karşılık olay deposu tarafından oluşturulan olaylar hem web sitesi hem de bordro sistemi tarafından kullanılabilir.

  • Gereksinimlerin değişiklik yapması durumunda gerçekleştirilmiş modellerin ve varlık verilerinin biçimini değiştirebilme esnekliği istediğinizde veya CQRS ile birlikte kullanıldığında, bir okuma modeli veya verileri kullanıma sunan görünümleri uyarlamanız gerekir.

  • CQRS ile birlikte kullanıldığında ve okuma modeli güncelleştirilirken son tutarlılık kabul edilebilir düzeyde olduğunda veya olay akışından gelen varlıkları ve verileri yeniden doldurmanın performans üzerindeki etkisi kabul edilebilir düzeyde olduğunda.

Bu düzen aşağıdaki durumlarda kullanışlı olmayabilir:

  • Küçük veya basit etki alanları, çok az iş mantığı olan veya hiç olmayan sistemler ya da geleneksel CRUD veri yönetim mekanizmalarıyla doğal olarak iyi çalışan, etki alanı olmayan sistemler.

  • Tutarlılığın ve verilerin görünümlerinde gerçek zamanlı güncelleştirmelerin gerekli olduğu sistemler.

  • Denetim kayıtlarının, geçmişin ve eylemleri geri alma ve yeniden yürütme özelliklerinin gerekli olmadığı sistemler.

  • Temel verilerde güncelleştirme çakışmalarıyla çok seyrek karşılaşılan sistemler. Örneğin, verileri güncelleştirmek yerine yoğun olarak veri ekleyen sistemler.

Örnek

Konferans yönetim sisteminin bir konferans için yapılan rezervasyonların sayısını izlemesi gerekir çünkü bunu yaparak olası bir katılımcı rezervasyon yapmaya çalıştığında hala yer kalıp kalmadığını denetleyebilir. Sistem, konferansın rezervasyonlarının toplam sayısını en az iki yoldan depolayabilir:

  • Sistem rezervasyonların toplam sayısı hakkındaki bilgileri, rezervasyon bilgilerinin tutulduğu veritabanında ayrı bir varlık olarak depolayabilir. Rezervasyonlar yapılırken veya iptal edilirken, sistem bu sayıyı gerektiği gibi artırabilir ve azaltabilir. Bu yaklaşım teorik olarak basittir ama kısa bir süre içinde çok fazla sayıda katılımcı yer rezervasyonu yaptırmaya çalışırsa ölçeklenebilirlik sorunlarına neden olabilir. Örneğin, rezervasyon süresi dolmadan önceki son gün veya buna yakın bir zamanda bu olabilir.

  • Sistem, rezervasyonlar ve iptaller hakkındaki bilgileri olay deposunda tutulan olaylar olarak depolayabilir. Ardından bu olayları yeniden yürüterek yer sayısını hesaplayabilir. Olayların sabit olma özelliğine bağlı olarak bu yaklaşım daha ölçeklenebilir olabilir. Sistemin yalnızca olay deposundan verileri okuyabilmesi veya olay deposuna veri ekleyebilmesi gerekir. Rezervasyonlar ve iptallerle ilgili olay bilgileri hiçbir zaman değiştirilmez.

Aşağıdaki diyagramda konferans yönetim sistemindeki yer rezervasyonu alt sisteminin olay kaynağını belirleme kullanılarak nasıl uygulanabileceği gösterilir.

Konferans yönetim sisteminde yer rezervasyonları hakkındaki bilgileri yakalamak için olay kaynağını belirleme kullanma

İki kişilik yer ayırmanın eylem sırası aşağıdaki gibidir:

  1. Kullanıcı arabirimi iki katılımcıya yer ayırmak için bir komut gönderir. Komut ayrı bir komut işleyici tarafından işlenir. Bir mantık parçası kullanıcı arabiriminden ayrılmıştır ve komut olarak gönderilen istekleri işlemekten sorumludur.

  2. Rezervasyonları ve iptalleri açıklayan olayları sorgulamak yoluyla, konferansın tüm rezervasyonları hakkındaki bilgilerin toplam değeri oluşturulur. Bu toplam değer SeatAvailability olarak adlandırılır ve toplam değerdeki verileri sorgulama ve değiştirme yöntemlerini gösteren bir etki alanı modeli içinde yer alır.

    Dikkate alınarak yapılan bazı iyileştirmeler anlık görüntüleri kullanmaktır (bu nedenle, toplamanın geçerli durumunu elde etmek için olayların tam listesini sorgulamanız ve yeniden yürütmeniz gerekm yok) ve toplam değerin önbelleğe alınmış bir kopyasını bellekte korumaktır.

  3. Rezervasyonları yapmak için komut işleyicisi etki alanı modeli tarafından ortaya konan bir yöntem çağırır.

  4. SeatAvailability toplam değeri, ayrılmış yerlerin sayısını içeren bir olay kaydeder. Toplam değerin olayları bir sonraki uygulayışında, kaç yer kaldığını hesaplamak için tüm rezervasyonlar kullanılacaktır.

  5. Sistem yeni olayı, olay deposundaki olay listesinin sonuna ekler.

Bir kullanıcı rezervasyonunu iptal ederse, sistem benzer bir süreç izler; yalnız bu kez komut işleyicisi rezervasyon iptal olayı oluşturan bir komut gönderir ve bunu olay deposuna ekler.

Olay deposu kullanmak, ölçeklenebilirliğe daha fazla kapsam sağlamanın yanı sıra konferansın rezervasyonları ve iptallerinin eksiksiz bir geçmişini veya denetim kaydını da sağlar. Olay deposundaki olaylar doğru kayıtlardır. Toplam değerleri başka bir yolla kalıcı hale getirmek gerekmez çünkü sistem olayları kolayca yeniden yürütebilir ve durumu zamanın herhangi bir noktasına geri yükleyebilir.

Olay Kaynağını Belirleme özelliğine giriş başlığı altında bu örnekle ilgili daha fazla bilgi bulabilirsiniz.

Sonraki adımlar

Bu düzen uygulanırken aşağıdaki düzenler ve yönergeler de yararlı olabilir:

  • Komut ve Sorgu Sorumluluğu Ayrımı (CQRS) düzeni. CQRS uygulamasına kalıcı bir bilgi kaynağı sağlayan yazma deposu çoğunlukla Olay Kaynağını Belirleme düzeninin bir uygulamasını temel alır. Ayrı arabirimler kullanarak uygulamada verileri okuyan işlemleri, verileri güncelleştiren işlemlerin nasıl ayrılacağını açıklar.

  • 1. Görünüm düzeni. Olay kaynağını belirleme temelinde bir sistemde kullanılan veri deposu normalde verimli bir sorgulamaya pek uygun değildir. Bunun yerine, yaygın bir yaklaşım düzenli aralıklarla veya veriler değiştirildiğinde verilerin önceden doldurulmuş görünümlerini oluşturmaktır. Bunun nasıl yapılabileceğini gösterir.

  • Telafi İşlem düzeni. Olay kaynağını belirleme deposundaki mevcut veriler güncelleştirilmez, bunun yerine varlıkların durumunu yeni değerlere geçiren yeni girdiler eklenir. Bir değişikliği geri çevirmek için telafi girdileri kullanılır çünkü yalnızca önceki değişikliği geri çevirmek mümkün değildir. Önceki bir işlemin gerçekleştirdiği çalışmanın nasıl geri alınacağını açıklar.

  • Veri Tutarlılığı İlkeleri. Olay kaynağını belirleme özelliği ayrı bir okuma deposuyla veya gerçekleştirilmiş görünümlerle kullanıldığında, okuma verileri hemen tutarlı olmaz, bunun yerine yalnızca sonunda tutarlı olur. Dağıtılmış veriler üzerinde tutarlılığı korumayla ilgili sorunları özetler.

  • Veri Bölümleme Kılavuzu. Ölçeklenebilirliği geliştirmek, çekişmeyi azaltmak ve performansı iyileştirmek üzere olay kaynağını belirleme kullanıldığında, veriler genellikle bölümlenir. Verilerin bağımsız bölümlere nasıl ayrılacağını ve ortaya çıkabilecek sorunları açıklar.