Bir modeli (Ürünü kontrol eden hizmet A (CMS) verildiğinde, sahip olduğu tek alanların id, başlık, fiyat) ve verilen modeli göstermek zorunda olan B (Nakliye) ve C (E-postalar) alanları olduğunu varsayalım. kaynak kullanımı yaklaşımında verilen model bilgilerini bu hizmetler arasında senkronize etmek nasıl? Ürün kataloğunun nadiren değiştiğini (ancak değiştiğini) ve gönderilerin ve e-postaların verilerine çok sık erişebilen yöneticilerin olduğunu varsayalım (örnek işlevler: B: display titles of products the order containedve C:) display content of email about shipping that is going to be sent. Hizmetlerin her birinin kendi DB'si vardır.
Çözüm 1
Ürünle ilgili tüm gerekli bilgileri etkinlik içinde gönder - bu, aşağıdaki yapı için anlamına gelir order_placed:
{
order_id: [guid],
product: {
id: [guid],
title: 'Foo',
price: 1000
}
}
Hizmet B ve C ürün bilgileri tablodaki productJSON özniteliğinde depolanırorders
Bu nedenle, gerekli bilgileri görüntülemek için yalnızca olaydan alınan veriler kullanılır
Sorunlar : B ve C'de hangi bilgilerin sunulması gerektiğine bağlı olarak, olaydaki veri miktarı artabilir. B ve C, Ürün hakkında aynı bilgileri gerektirmeyebilir, ancak etkinliğin her ikisini de içermesi gerekir (etkinlikleri ikiye ayırmazsak). Belirli bir olayda belirli veriler mevcut değilse, kod bunu kullanamaz - verilen Ürüne bir renk seçeneği eklersek , B ve C'deki mevcut siparişler için, etkinlikleri güncellemedikçe ve sonra yeniden çalıştırmadıkça verilen ürün renksiz olacaktır .
Çözüm 2
Etkinlik sırasında yalnızca ürün kılavuzunu gönderin - bu, aşağıdaki yapı anlamına gelir order_placed:
{
order_id: [guid],
product_id: [guid]
}
B ve C hizmetleri hakkında ürün bilgileri tabloda product_idöznitelikte depolanırorders
A/product/[guid]Uç noktaya bir API çağrısı yapılarak gerektiğinde ürün bilgileri B ve C servisleri tarafından alınır
Sorunlar : Bu B ve C'yi A'ya (her zaman) bağımlı kılar. Ürünün şeması A'da değişirse, bunlara bağlı tüm hizmetlerde (aniden) değişiklikler yapılmalıdır.
Çözüm 3
Etkinlik sırasında yalnızca ürün kılavuzunu gönderin - bu, order_placed için aşağıdaki yapı anlamına gelir:
{
order_id: [guid],
product_id: [guid]
}
Hizmetler B ve C'de ürün bilgileri productstabloda saklanır ; hala var product_idilgili orderstablo ama replikasyonu var products, A, B ve C arasında veri; B ve C, Ürün hakkında A'dan farklı bilgiler içerebilir
Hizmetler B ve C oluşturulduğunda ürün bilgileri eklenir ve ürünler hakkında bilgi her A/productuç değiştiğinde (tüm ürünler için gerekli bilgileri gösteren) veya A'ya doğrudan DB erişimi gerçekleştirerek ve verilenler için gerekli ürün bilgilerini kopyalayarak güncellenir. hizmet.
Sorunlar : Bu, B ve C'yi A'ya bağımlı hale getirir (tohumlama sırasında). Ürünün şeması A'da değişirse, bunlara bağlı tüm hizmetlerde (tohumlama sırasında) değişiklikler yapılmalıdır.
Anladığım kadarıyla, doğru yaklaşım çözüm 1 ile gitmek ve ya belirli bir mantık başına olay geçmişini güncellemek olacaktır (Ürün kataloğu değişmediyse ve görüntülenecek renk eklemek istiyorsak, mevcut durumu almak için geçmişi güvenli bir şekilde güncelleyebiliriz Ürünlerin ve etkinliklerde eksik verileri doldurun) veya verilen verilerin mevcut olmamasını sağlayın (Ürün kataloğu değiştiyse ve görüntülenecek renk eklemek istiyorsak, o zamana kadar belirtilen Ürünün zamanında renkli olsun ya da olmasın - önceki katalogdaki tüm Ürünlerin siyah olduğunu ve etkinlikleri veya kodu güncelleyerek hitap ettiğini varsayabiliriz)
updating event historydemek istediğim: tutarlı olay şemasını korumak için tüm olayları gözden geçirin, bunları bir akıştan (v1) başka bir akışa (v2) kopyalayın.
display image at the point when purchase was made) var olamaz veya olamaz (niyetini temsil eder display current image as it within catalog)
updating event history- Olay kaynağı olay tarih gerçeğin kaynağıdır ve asla değiştirilmemeli, sadece ilerlemelidir. Olaylar değişirse, olay sürümlendirmesini veya benzer çözümleri kullanabilirsiniz, ancak olaylarınızı belirli bir zamana kadar tekrar oynatırken verilerin durumu o noktadaki gibi olmalıdır.