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 işlemi, genellikle verileri kilitleyen işlemleri kullanarak verileri mağazadan okumak, bazı değişiklikler yapmak ve verilerin geçerli durumunu yeni değerlerle güncelleştirmektir.

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

• CRUD sistemleri, güncelleştirme işlemlerini doğrudan bir veri deposuna karşı gerçekleştirir. Bu işlemler performansı ve yanıt hızını yavaşlatabilir ve gerektirdiği işlem yükü nedeniyle ö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ı bir günlüğe kaydeden başka bir denetim mekanizması yoksa, 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 ekler, siparişe ürün ekler veya kaldırır ve sevkiyat bilgilerini ekler. Bu değişiklikleri açıklayan olaylar işlenebilir ve gerçekleştirilmiş görünümü güncelleştirmek için kullanılabilir.

Herhangi bir noktada uygulamaların olayların geçmişini okuması mümkündür. Daha sonra, bir varlığın geçerli durumunu yeniden yürüterek ve bu varlıkla ilgili tüm olayları kullanarak varlığın geçerli durumunu gerçekleştirmek için kullanabilirsiniz. Bu işlem, isteği işlerken bir etki alanı nesnesinin gerçekleştirilmesi için isteğe bağlı olarak gerçekleşebilir. Öte yandan işlem, varlığın durumunun sunu katmanını desteklemek üzere gerçekleştirilmiş bir görünüm olarak depolanabilmesi için zamanlanmış bir görev aracılığıyla gerçekleşir.

Ş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ı 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şlem, işlemlerin işlenmesi sırasında çekişme olmamasıyla birlikte, özellikle sunu düzeyi veya kullanıcı arabirimi için uygulamalar için performansı ve ölçeklenebilirliği büyük ölçüde geliştirebilir.

• Olaylar, olay tarafından temsil edilen eylemi tanımlamak için gereken tüm 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. Olayları kullanmak, uygulama 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 yalnızca ekleme depolaması, bir veri deposuna yönelik eylemleri izlemek için kullanılabilecek bir denetim izi sağlar. Olayları istediğiniz zaman yeniden yürüterek geçerli durumu gerçekleştirilmiş görünümler veya projeksiyonlar olarak yeniden oluşturabilir ve sistemin test edilmesine ve hata ayıklamaya yardımcı olabilir. Ayrıca, değişiklikleri iptal etmek için telafi olayları kullanma gereksinimi, ters çevrilen değişikliklerin geçmişini sağlayabilir. Model geçerli durumu depoladıysa bu özellik geçerli olmaz. Olay listesi, uygulama performansını analiz etmek ve kullanıcı davranışı eğilimlerini algılamak için de kullanılabilir. Alternatif olarak, diğer yararlı iş bilgilerini almak 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. Bir uygulamanın bir isteği işlemenin sonucu olarak olay deposuna olay eklemesi, yayımlanan olaylar ve bunları işleyen olayların tüketicileri arasında biraz gecikme olur. Bu süre içinde, olay deposuna varlıklarda yapılan başka değişikliklerin açıklandığı yeni olaylar gelmiş olabilir. Sistem, bu senaryolarda nihai tutarlılığı hesaba katmanız için tasarlanmalıdır.

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, stok envanterinde azalma olduğunu gösteren bir olay, söz konusu öğe için bir sipariş alınırken veri deposuna gelebilir. Bu durum, müşteriye danışmanlık yaparak veya bir geri sipariş oluşturarak iki işlemi uzlaştırma gereksinimine neden olur.

Olay yayını en az bir kez olabilir ve bu nedenle olayların tüketicileri bir kez etkili olmalıdır. Olay birden çok kez işlendiyse olayda açıklanan güncelleştirmeyi yeniden uygulamaları gerekir. Bir tüketicinin birden çok örneği, verilen toplam sipariş sayısı gibi bir varlığın özelliğini koruyabilir ve toplayabilir. Siparişe göre bir olay gerçekleştiğinde toplamayı artırmada yalnızca birinin başarılı olması gerekir. Bu sonuç olay kaynağını belirlemenin önemli bir özelliği olmasa da, her zamanki uygulama kararıdır.

Seçilen olay depolamasının uygulamanız tarafından oluşturulan olay yükünü desteklemesi gerekir.
Bir olayın işlenmesinin bir veya daha fazla yeni olay oluşturmayı içerdiği senaryolara dikkat edin çünkü bu durum sonsuz döngüye neden olabilir.

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 Eve taşındı, Kapalı hesap veya Vefat etti gibi belirli olay türleri dizisi olarak yakalanabilir.

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

• Oluşan olayları kaydetmek istediğinizde, sistemin durumunu geri yüklemek, değişiklikleri geri almak veya geçmiş ile denetim günlüğünü tutmak için bunları yeniden oynatmak için. Örneğin, bir görev birden çok adım içerdiğinde, güncelleştirmeleri geri döndürmek için eylemler yürütmeniz ve ardından verileri tutarlı bir duruma geri getirmek için bazı adımları yeniden yürütmeniz gerekebilir.

• Olayları kullandığınızda. Uygulamanın çalışmasının doğal bir özelliğidir ve çok az geliştirme veya uygulama çalışması gerektirir.

• Bu eylemleri uygulamak için gereken görevlerden veri girişi veya güncelleştirme işlemini ayırmanız gerektiğinde. Bu değişiklik kullanıcı arabirimi performansını geliştirmek veya olaylar gerçekleştiğinde eylemde bulunan diğer dinleyicilere olayları dağıtmak olabilir. Örneğin, bir bordro sistemini gider gönderimi web sitesiyle tümleştirebilirsiniz. Web sitesinde yapılan veri güncelleştirmelerine yanıt olarak olay deposu tarafından tetiklenen olaylar hem web sitesi hem de bordro sistemi tarafından kullanılacaktır.

• Gereksinimler değişirse veya CQRS ile kullanıldığında gerçekleştirilmiş modellerin ve varlık verilerinin biçimini değiştirebilmek için esneklik istiyorsanız, okuma modelini veya verileri kullanıma sunan görünümleri uyarlamanız gerekir.

• CQRS ile kullanıldığında ve okuma modeli güncelleştirilirken nihai tutarlılık kabul edilebilir veya bir olay akışından varlıkları ve verileri yeniden doldurmanın performans etkisi kabul edilebilir.

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 izlerinin, geçmişin ve geri alma ve yeniden yürütme eylemlerinin gerekli olmadığı sistemler.

• Temel alınan verilerde çakışan güncelleştirmelerin yalnızca düşük olduğu sistemler. Örneğin, verileri güncelleştirmek yerine yoğun olarak veri ekleyen sistemler.

İş yükü tasarımı

Bir mimar, Azure İyi Tasarlanmış Çerçeve yapılarında ele alınan hedefleri ve ilkeleri ele almak için olay kaynağını belirleme düzeninin iş yükünün tasarımında nasıl kullanılabileceğini değerlendirmelidir. Örneğin:

Herhangi bir tasarım kararında olduğu gibi, bu desenle ortaya konulabilecek diğer sütunların hedeflerine karşı herhangi bir dengeyi göz önünde bulundurun.

Örnek

Konferans yönetim sisteminin bir konferans için tamamlanan rezervasyon sayısını izlemesi gerekir. Bu şekilde, olası bir katılımcı rezervasyon yapmaya çalıştığında hala kullanılabilir koltuk olup olmadığını kontrol edebilir. 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.

İ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ınması gereken bazı iyileştirmeler anlık görüntüler kullanmaktır (böylece toplamanın geçerli durumunu elde etmek için olayların tam listesini sorgulamanız ve yeniden yürütmeniz gerekmez) ve toplamanın önbelleğe alınmış bir kopyasını bellekte tutmaktı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.

Ölçeklenebilirlik için daha fazla kapsam sağlamaya ek olarak, bir olay deposu kullanmak, bir konferans için rezervasyonların ve iptallerin tam geçmişini veya denetim kaydını da sağlar. Olay deposundaki olaylar doğru kayıtlardır. Sistem olayları kolayca yeniden yürütebildiği ve durumu belirli bir noktaya geri yükleyebildiği için toplamaları başka bir şekilde kalıcı hale getirmek gerekmez.

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

Sonraki adımlar

• Nesne-ilişkisel empedans uyuşmazlığı

• Veri Tutarlılığı Temel Bilgileri. Olay kaynağını ayrı bir okuma deposu veya gerçekleştirilmiş görünümlerle kullandığınızda, okuma verileri hemen tutarlı olmaz. Bunun yerine, veriler yalnızca sonunda tutarlı olur. Bu makalede, dağıtılmış veriler üzerinde tutarlılığı korumayla ilgili sorunlar özetleniyor.

• Veri Bölümleme Kılavuzu. Ölçeklenebilirliği geliştirmek, çekişmesini azaltmak ve performansı iyileştirmek için olay kaynağını kullandığınızda veriler genellikle bölümlenmiş olur. Bu makalede verilerin ayrı bölümlere nasıl bölündüğü ve ortaya çıkabilecek sorunlar açıklanmaktadır.

• Martin Fowler'ın blogu:

  • Olay Kaynağını Belirleme
  • Martin Fowler'ın Kurumsal Uygulama Mimarisi web sitesinde anlık görüntü

İlgili kaynaklar

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.

• Gerçekleştirilmiş Görünüm düzeni. Olay kaynağını belirlemeyi temel alan bir sistemde kullanılan veri deposu genellikle verimli sorgulama için 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.

• Telafi İşlemi düzeni. Bir olay kaynak 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 tersine çevirmek için telafi girdileri kullanılır çünkü önceki değişikliği tersine ç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.