Sürücüler Etkinliği, Bölüm 3: Olaylar hakkında nasıl konuşulur
Bu serinin ikinci bölümünde hangi yapıların etkinliklere dayalı bir mimari yaptığını gördük: komutlar, olaylar, projeler ve etkinlikler akıyor. Olaylar bu konuda merkezi bir rol oynar: Sistemin ne olduğunu söylediği dildir.
Golo Roden, yerel web GmbH'nin kurucusu ve CTO'sudur. Olaylara ve hizmetlere dayalı olarak dağıtılmış mimarilere özellikle dikkat ederek web ve bulut uygulamalarının ve arıların anlayışı ve geliştirilmesi ile ilgilidir. Yol gösterici ilkesi, yazılımın gelişiminin kendi başına bir son olmaması, ancak her zaman aşağıda bir profesyonellik izlemesi gerektiğidir.
Ama bir olay tam olarak nedir? Buna ne diyorsun? Ve teknik olarak makul, anlaşılabilir ve kullanışlı olmasını nasıl sağlıyorsunuz?
Etkinlikler teknik gerçeklerdir
Bir olay, geçmişte olan ve teknik olarak önemli olan bir şeyi açıklar. Bunlar teknik detaylar (“alıcı istek” veya “açık veritabanı bağlantısı” değil), “kitap ödünç alındı”, “detay hesaplandı” veya “adres kaydedildi”.
Bu olaylar profesyonellik ve teknoloji arasındaki en küçük ortak dildir. Devletteki kararları, süreçleri ve değişiklikleri bir düşünce olarak değil, birincil model olarak belgeliyorlar.
Profesyonellik Dili
Olaylar, uzmanlar tarafından (veya her şeyden önce) anlaşılacak şekilde formüle edilmelidir ve – ideal olarak – onlarla bile geliştirilmiştir. Hem şirket olasılığını hem de teknik uygulamayı getiren ortak bir dil bulma meselesidir.
İyi bir olay aşağıdaki kriterleri karşılar:
- Bir gerçeği, niyeti, arzuyu, prognozu tanımlar.
- Alan bakış açısından, anlaşılabilir ve anlaşılabilir.
- Uygulandığı gibi değil, ne olduğunu atar.
- “Oluşturulan kitap” değil, “kitap envanterde dahil edildi”.
- “Güncellenmiş kitap” değil, “kitap atandı”.
Etkinlikler kayıt hatları değil, hata ayıklama baskısı ve saf taşıma formatı yok. Gerçekte, sistemin ne ifade etmesi gerektiğinin teknik çekirdeğini oluştururlar. Bu nedenle, bir iş kitabında ses gibi bir etkinlik hayal edebilirsiniz – neler olduğunu ve temel kararları verilen kalıcı olarak belgeleyen bir şey.
Olayları tamamen teknik bir yardım olarak gören herkes, anlamlarını sulandırma riskini taşır. Bunun yerine, olaylar hassasiyetle atanmalı ve sabit tutulmalıdır – çünkü sistemin uzun vadeli gerçeğini oluştururlar.
İstikrar ve geliştirme
Olaylar genellikle değişmezdir. Oluşturulur, kaydedilirler ve sonra artık değişmezler. Bu, bir zamanlar yayınlanan bir etkinliğin hikayenin bir parçası olduğu ve bu şekilde korunması gerektiği anlamına gelir. Gereksinimler değişirse, mevcut olayları “uyarlamak” değil, ek olaylar sunmak gereklidir.
Bu istikrar, projeleri yeniden yapılandırmanıza, süreçlerin hata ayıklamasını ve mevcut geçmişe dayalı yeni gereksinimleri uygulamanızı sağlar, örneğin eski olayları yeni bir mantıkla yeniden çalıştırarak.
Yayın ve tepki
Bir olay oluşturulursa, yalnızca sisteminizde kullanılamaz, aynı zamanda yayınlanır. Bu genellikle bir mesaj mesajı veya bir etkinlik otobüsü yoluyla olur. Bu, sistemin diğer bölümlerinin (veya diğer sistemlerin) doğrudan bir bağlantı olmadan reaksiyona girmesini sağlar.
Bu, olayların sadece veri olmadığı anlamına gelir: bunlar bir sözleşme. Belli bir durum meydana gelen ve ona güvenebileceğiniz bir söz.
Sırada ne var?
Bir sonraki bölümde, olaylara dayalı mimarinin gerçekten anlamını ve sık sık karıştırıldığını inceliyoruz. Çünkü her yerde olayların olduğu olaylara dayanan bir mimari de var.
(Mayıs)
Ne yazık ki, bu bağlantı artık geçerli değil.
Boşa harcanan eşyalara olan bağlantılar, 7 günlük daha büyükse veya çok sık çağrılmışsa gerçekleşmez.
Bu makaleyi okumak için bir Haberler+ paketine ihtiyacınız var. Şimdi yükümlülük olmadan bir hafta deneyin – yükümlülük olmadan!