Read Model'i Ne Zaman Ayırmalı
Liste sorgusu yazmayı kilitleyince

İlk refleks, her liste için ayrı projeksiyon. Refleks, iki yazma yolu ve bir gecikme sınıfı demek. Gecikmeyi konuşmadan projeksiyon, vitrinde eski fiyat bırakır. O yüzden sorum basit: bu okuma, yazmayı incitiyor mu?
İncitiyorsa ayırırım. Sipariş yazması, admin'in altı join'li ekranında kilit bekliyorsa, o ekranın kendi tablosu olsun. İncitmiyorsa {SELECT} durur. Indeks, çoğu gün projeksiyondan ucuz.
CREATE TABLE order_inbox (
order_id uuid PRIMARY KEY,
buyer_name text NOT NULL,
total numeric(12,2) NOT NULL,
status text NOT NULL,
placed_at timestamptz NOT NULL
);
-- yazma yolundan, aynı işlem veya outbox sonrası
INSERT INTO order_inbox (order_id, buyer_name, total, status, placed_at)
VALUES ($1, $2, $3, $4, $5)
ON CONFLICT (order_id) DO UPDATE
SET buyer_name = EXCLUDED.buyer_name,
total = EXCLUDED.total,
status = EXCLUDED.status;
Aynı veritabanı, ayrı tablo. Event store şart değil. Şart olan, yazanın kopyayı bilmesi veya rölenin kopyayı doldurması. İkisinden biri yoksa model beş dakika geride kalır ve kimse ölçmez.
Ayırmadığım yer: tek satır detay, az satırlı tanım listesi, yazmadan hemen sonra okunan 'kaydet ve göster'. Orada kopya, kullanıcının kendi yazısını görmemesidir. Bunu TTL ile örtmek, yalanı geciktirmek.
Read model bir ölçek hikâyesi olarak satılır. Benim gördüğüm çoğu ihtiyaç, ölçek değil, kilit ve şekil. Şekil çok farklıysa — vitrin kartı, yazma satırından uzak — kopya haklı. Şekil aynıysa, önce sorguyu düzeltin. CQRS rozeti, bozuk {SELECT} 'i iyileştirmez.
Yorumlar
Yorumlar (0)
Yorumlar üyelere açık. Üye ol · Giriş yap