Bu serinin önceki bölümleri olayların önderliğindeki mimarinin temelleriyle karşılaştıktan sonra, şimdi somut olmalı. Sürekli bir örnek kullanarak, bir sistemin tablolara, veritabanlarına veya arılara dayalı değil, teknik süreçlerin kendilerine dayanarak nasıl sıfırdan modellenebileceğini göstereceğim.
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.
Bu örnek kasıtlı olarak basit, ama yine de gerçekçi: bir şehir kütüphanesi.
Profesyonelliğe dikkat
Bu kütüphanede, kullanıcılar kitapları ödünç alabilir, genişletebilir ve iade edebilir. Kitapları çok geç iade ederseniz, hatırlatma maliyetleri düşecektir. Tüm bu süreçler sabit teknik kurallara uyuyor – ve bu da mimari yaklaşımımızın geldiği yerdir: önce veri yapıları istemiyoruz, ancak neler olup bittiğini.
Bu, olaylara dayalı mimarinin ne olduğunu çabucak fark etti: olaylar. Mevcut durumu merkezi olarak modellemek yerine, bu duruma yol açan süreçlere odaklanıyoruz. Bir sistem sadece bir şeyin nasıl olduğunu açıklamaz, aynı zamanda ne olduğunu söyler.
Etki alanında ne olur?
Bir uygulama düşünülmeden önce, bir perspektif değişikliğine başlayalım: Alan adında hangi profesyonel olarak alakalı olaylar ortaya çıkıyor?
Şehir kütüphanemiz için tipik örnekler hızlı bir şekilde ortaya çıkar:
- “Kitap ödünç alındı.”
- “Kitap iade edildi.”
- “Kiralama dönemi uzatıldı.”
- “Dönüş geç kaldı.”
- “Dunning'in vergisi bekleniyordu.”
- “Dunning'in vergisi ödendi.”
Bu olaylar somut gerçekleri tanımlar – basit koşullar değil, değişiklikler. Olduklarında ve olayın yapısına bağlı olarak olanları yaparlar.
Tipik bir süreç
Klasik bir kredi süreci örnek olarak hareket eder. Kullanıcı bir kitap ödünç verir: Sistem “kitap ödünç alındı” oluşturur. Kitap zamanında iade edilmezse, sistem geri dönüşün geç olduğunu belirler: “Dönüş geçti”. Sonuç olarak, bir hatırlatma ücreti alınır. Bu aynı zamanda bir etkinlik: “Dunning Komisyonu geldi”. Kullanıcı bu komisyona ödeme yaparsa, bir sonraki etkinlik gerçekleşir: “Hatırlatma ücreti ödendi”. Ve son olarak: “Kitap iade edildi”.
Çarpıcı olan: Kitabın durumunu merkezi olarak arşivlemek gerekli değildir, ancak tüm süreç olayların sırasından türetilir. Mevcut durum, tarih tarafından herhangi bir zamanda yeniden yapılandırılabilir. Ve daha da fazlası: tüm hikaye anlaşılabilir olmaya devam ediyor.
Komutlar olaylara yol açar
Tabii ki, olaylar yalnız doğmaz. Çoğu zaman, sözde komutlar onlardan önce veya bir şey yapma sistemini talep eder. Bir kullanıcı bir kitap ödünç almak istiyorsa, bir komuta “kredi defteri” olarak gönderir. Sistem komutun izin verilip verilmediğini kontrol eder: Bu durum, ilgili olayı yaratır: “Kitap ödünç alındı”.
Ayrılık önemlidir: komutu ifade etme niyetleri, olayların belgelerinin gerçekleri. Tüm komutlar bir olaya yol açmaz: Gereksinimler karşılanmazsa, bir komut reddedilebilir. Bu ayrılık, süreçleri tam olarak modellemeye ve doğru bir şekilde uygulamaya yardımcı olur.
Projeler durumu görünür kılıyor
Mevcut durum, istediğiniz zaman depolanan olay tarafından hesaplanabilir. Bunu yapmak için, söz konusu projelere ihtiyaç duyulur – okunaklı, sorgu ziyaretleri sisteme. Bir proje şu şekilde soruları cevaplar: Hangi kitaplar bir kullanıcı ödünç aldı? Hangi hatırlatma komisyonları açık? Son zamanlarda belirli bir kitap ne zaman geri döndü?
Bu projeler mantıklarını içermiyor. Sadece olayların detaylandırılmasına dayanırlar. Büyük avantajınız: Sistemin diğer kısımları üzerinde bir etkisi olmadan belirli uygulamalar için özel olarak optimize edilebilirsiniz.
Mimarlık profesyonelliği takip eder
Bu yaklaşım, profesyonelliğe yakından yönelik bir mimarlık yaratır. Teknik eserler yerine, gerçek süreçler merkezdedir. Teknik dil sistemin yapısal bir tedarikçisi haline gelir. Olaylara sadece dahili işleme için bir temel olarak değil, aynı zamanda bileşenler veya sistemler arasında bir iletişim aracı olarak, örneğin bir mesaj aracılığıyla ipucu yayınlayarak ve diğer hizmetlere abone olarak da gereklidir.
Avantajlar açıktır: sistemler daha modüler, daha anlaşılır ve daha iyi beklemeye başlar. Değişiklikler anlaşılabilir ve yeni gereksinimler genellikle mevcut olaylara yeni tepkiler eklenerek uygulanır. Yazma ve okumanın ayrılması (komut sorgusunun ayrılması, CQRS) de daha net sorumluluklara ve daha iyi ölçeklenebilirliğe yol açar.
Çözüm
Şehir kütüphanesinin bu örneği, olaylara dayalı olayları nasıl düşünebileceğinizi göstermektedir. Belirleyici faktör somut teknik uygulama değil, perspektif değişikliği: mevcut durumdan uzak, teknik olayların tarihine doğru.
Bu serinin bir sonraki ve son kısmı, gerçek bir projedeki olaylar tarafından yönetilen mimarlıkla nasıl başlayacağınızı endişelendirecek: hangi rollerin dahil olduğu, uzmanlarla nasıl etkinlikler geliştirileceği ve hangi pasajların özellikle ilk deneyler için uygun olduğu.
(Mayıs)
Bir yanıt yazın