Sınırla başlayın
Event’ler domain tasarımının kestirme yolu değildir. Sınırları daha görünür kılar ve belirsiz sahipliği daha hızlı cezalandırır. Bir event’i adlandırmadan önce onu üreten iş kararını, bu kararın sahibi olan sistemi ve tüketicilerin güvenebileceği asgari sözü yazın.
MakbuzGönder gibi komutlar yerine SiparişKabulEdildi gibi olguları tercih edin. Bir olgunun birden çok bağımsız tüketicisi olabilir; komut ise sahipliği sessizce devreder ve görülmesi daha zor bir bağımlılık yaratır.
Örnek senaryo: yinelenen teslimat
Örnek senaryo: ödeme servisi PaymentConfirmed event’ini yayımlar ancak mesaj aracısı zaman aşımından sonra aynı mesajı iki kez teslim eder. Gönderim handler’ı event kimliğini sonucuyla birlikte tek işlemde saklar. İkinci teslimatta kimliği görür ve yeni gönderi oluşturmak yerine kayıtlı sonucu döndürür.
Bu örnek açıklama amaçlıdır; gerçek bir üretim sistemi sonucu değildir. Amaç sözleşmeyi görünür kılmaktır: kimlik, sıralama varsayımları, yeniden deneme politikası ve işin kalıcı hâle geldiği nokta.
Ödünleşimi açıkça seçin
En-az-bir teslim, birden çok sistemde tam-bir-kez davranışı vaat etmeye çalışmaktan genellikle daha kolay işletilir. Bedeli idempotent handler’lar, tekrar ayıklama kaydı ve daha iyi izlerdir. Tam-bir-kez söylemi daha güvenli duyulabilir; ancak çoğu zaman yeniden denemeleri ortadan kaldırmak yerine altyapının arkasına saklar.
type Event<T> = {
id: string
payload: T
occurredAt: Date
}
export async function publish<T>(event: Event<T>) {
await stream.append(event)
}Kısa inceleme kontrol listesi
Yayına almadan önce her event’in bir sahibi ve kararlı kimliği olduğunu; handler’ların yeniden oynatmayı tolere ettiğini; şemaların uyumlu sürümlendiğini; yeniden denemelerin sınır ve bekleme politikasına sahip olduğunu; başarısız mesajların sorumlu bir operatöre ulaştığını; izlerin ilk isteği tüm tüketicilere bağladığını doğrulayın.