(Resim: Allard Buijze)
Allard Buijze, AxonIQ'un kurucusu ve CTO'sudur. Programlamaya olan tutkusunu altı yaşında geliştirdi. Profesyonel kariyerinde büyük ve küçük şirketlerin yüksek performanslı ve ölçeklenebilir uygulamaların geliştirilmesine destek olmuştur. Artık misyonu, etki alanına dayalı tasarım, komut sorgusu sorumluluğu ayrımı (CQRS) ve olaya dayalı mimari kavramlarından yararlanarak büyük sistemlerin uygulanmasını basitleştirmektir.
Duyuru
iX: Mimari bir yaklaşım olarak olay kaynağıyla ilk kez nasıl karşılaştınız?
Bu 2009 yılında oldu. O zamanlar hâlâ bir danışmanlık firmasında çalışıyordum ve birçok projeden sorumluydum. Çözümün karmaşıklığının, çözmeye çalıştığımız sorunun karmaşıklığından çok daha yüksek olmasından bıkmıştım.
Farklı konseptler denemeye başladım. Etki alanı odaklı tasarım bana çok yardımcı oldu. Ama başka bir şeyin daha olması gerekiyordu.
Bu noktada Greg Young'un bir ders sunumunu gördüm. Okuma tarafını yazma kısmından ayırmayı önerdi. Ayrıca bir uygulamada yapılan tüm değişikliklerin olay olarak temsil edilmesi ve saklanması kavramını da tanıttı. Bugün bu kavramları CQRS ve Event Sourcing olarak biliyoruz.
Bu fikirleri denemeye başladım. Bu deneyin sonucu Axon Çerçevesi olarak bilinmeye başlandı.
Olay kaynağı bulma ve olay fırtınası (bir etki alanını bir dizi etki alanı olayı olarak modellemeye yönelik işbirlikçi bir yaklaşım) doğal tamamlayıcılar gibi görünüyor. Tüm olay fırtınası etki alanları, etki alanı olaylarının kaydedilmesi ve yeniden oynatılması yoluyla olay kaynağıyla uygulanabilir mi?
Etkinlik kaynağı, etkinlik fırtınası için gerçekten iyi bir seçimdir. Biraz farklı bir süreç olan etkinlik modellemenin, etkinlik kaynak bulma topluluğunda giderek daha popüler hale geldiğini de görüyoruz.
Ne yazık ki olayları kaydedip bir gün sonraya bırakmak kadar kolay değil. Etkinlik kaynağı seçerken bu etkinlikleri nasıl saklayacağınızı dikkatlice düşünmelisiniz çünkü bunlardan çok sayıda olacak. Ayrıca bunlara çok verimli bir şekilde erişebilmeniz gerekir. Olay kaynağı bulma alanına girişen herkesin bu görev için tasarlanmış mevcut bir çerçeveyi veya araçları kullanmasını şiddetle tavsiye ederim. Bu size çok fazla zaman kazandıracak ve hayal kırıklığı yaratacaktır. Kafka pek çok şey için faydalıdır ancak olay kaynağı bunlardan biri değildir.
Ama ikisi birlikte çok iyi gidiyor. Olay odaklı bir sistem oluşturmak istiyorsanız alanınızı keşfetmek ve sisteminizi tasarlamak için olay fırtınası veya olay modelleme gibi bir teknik kullanmalısınız. Çünkü burada odak noktası, sisteme atadığımız statik veri nitelikleri değil, sistemde ne olduğudur. Bir sistemi tasarlamaya yönelik herhangi bir veri odaklı yaklaşım, olayın kaynak kullanımıyla uygulanmasını engeller.
Olay kaynağı kullanımının belirli bir soruna doğru çözüm olup olmadığını değerlendirmenin en iyi yolu nedir?
Her zaman etkinlik kaynağının niş bir çözüm olduğunu düşündüm. Bu yalnızca, sisteminizin geçmişini denetim amacıyla izlemekle gerçekten ilgileniyorsanız anlamlıdır. Yanılmışım.
Olay kaynağı güçlü bir kavramdır. Gelecekte ihtiyaç duyabileceğiniz bilgileri bugünden edinmenizi sağlar. Konuştuğum birçok geliştirici bugün önemli olana odaklanmayı tercih ediyor çünkü diğer bileşeni daha sonra oluşturabileceğinizi biliyorsunuz. Olay kaynağı belirli bir düzeyde karmaşıklığa sahip olsa da, karmaşık sistemleri geleneksel veri odaklı yaklaşımlardan çok daha iyi yönetmenize olanak tanır. Ayrıca sistem sorunlarını gidermek veya verilerinizdeki anormallikleri açıklamak için kullanabileceğiniz çok güvenilir, tek bir gerçek kaynak sağlar.
Olay kaynağı bulmanın doğru yöntem olup olmadığını hızlı bir şekilde belirlemek için, sistemi olay modellemeyi kullanarak tasarlamanızı tavsiye ederim. İyi çalışıyorsa ve bir sistemin davranışı komutlarla, olaylarla ve sorgularla ifade edilebiliyorsa olay kaynağı bulma doğru yaklaşım olabilir.
Olay kaynağı kullanımı, geliştiricileri sistemin durumuna değil davranışına odaklanmaya zorlar. Bu genellikle geliştiriciler ve iş paydaşlarının yazılım gereksinimleri arasında daha iyi bir koordinasyona yol açar. İşletme ile yazılım arasındaki mesafe küçüldüğünde, değişen gereksinimleri karşılamak için nerede değişiklik yapılması gerektiğini anlamak daha kolay hale gelir.
Olay kaynağına ilk kez girişecek olanlar için küçük bir uyarı: Olay kaynağı sağlamayı olay akışıyla karıştırmayın. Ayrıca, olay kaynağını ilk kez kullanırken öğrenme eğrisini karmaşıklıkla karıştırmayın. Nasıl çözeceğinizi bildiğiniz ancak olay kaynağı bulma konusunda daha zor görünen görevler olabilir. Bu öğrenme eğrisinin bir parçası.
Olay kaynağının uygulanmasında düzenli, uygunsuz kararlar gözlemlediniz mi? Evet ise hangileri? Bu hataların neden sıklıkla yapıldığına dair bir hipoteziniz var mı?
Evet, bazı yaygın hatalar var. Şimdiye kadarki en büyük hata CRUD (Oluştur, Oku, Güncelle ve Sil) olaylarının kullanılmasıdır. İş mantığındaki gerçek düşünceyi değil, veri değişikliklerini tanımlarlar. Bu CRUD etkinlikleri gelecekte çok daha az yararlı olma eğilimindedir. Bu, onları korursak faydalarından gerçekten yararlanamayacağımız anlamına gelir.
Bu hataların ilişkisel veri modelleri üzerine düşünmek üzere eğitildiğimiz için yapıldığından şüpheleniyorum. Bu üniversitede başlar ve profesyonel hayata devam eder. Birinden size bir sistemin ne yaptığını açıklamasını isteyin; genellikle verinin tüm olası özelliklerinden bahsederek başlayacaklardır.
Olay fırtınası ve olay modelleme gibi teknikler de burada yardımcı olur. Gerçekten davranışa odaklanırlar ve koşulları en sona koyarlar. İlk seferinde rahatsızlık hissedeceksiniz, ancak genellikle daha sonra çok çabuk ikinci doğanız haline gelecektir.
Olay odaklı sistemler oluşturmaya başarılı bir şekilde başlamak isteyen bir yazılım mühendisinin öğrenme eğrisini nasıl tanımlarsınız? Özel beceriler veya teknik yöntemler gerekli mi? Nereden başlayacağınıza dair tavsiyeniz var mı?
Deneyimler, olay kaynağına yönelik öğrenme eğrisinin çok dik olmadığını göstermiştir. Çok sayıda genç ve kıdemli geliştiriciye, mimara ve hatta iş adamına ders verdim. Kıdemli geliştiriciler en fazla zorluğu yaşıyor.
En büyük sorunun aslında öğrenmeme eğrisi olduğu ortaya çıktı. Çoğu insanı geride tutan şey, veri zihniyetini terk etmektir.
Doğru araçlar ve olayları başlangıç noktası olarak alan iyi bir tasarım yöntemiyle teknik hususlar o kadar da karmaşık değildir. Bir zamanlar alet çantamızda bulunan sözde ortak çözümlerden bazıları artık geçerliliğini yitirmiştir. Bunun için başka teknikleri öğrenmeliyiz. Nihai tutarlılık modeliyle daha geniş ölçekte ilgilenmeyi öğrenseydik daha iyi olurdu.
En önemli şey kendinizin deneyim kazanmasıdır. Öncelikle üzerinde çalıştığınız şeyin küçük, basitleştirilmiş bir versiyonunu oluşturmaya çalışın. “Veri tuzağı hakkında düşünmek”ten sakının; bunun o kadar da zor olmadığını göreceksiniz.
Röportajı Lukas Zühl gerçekleştirdi.
(Resim: iSAQB)
iSAQB Yazılım Mimarisi Buluşması 2024 bu yıl yine sahada gerçekleştirilecek. Organizatörler, Uluslararası Yazılım Mimarisi Yeterlilik Kurulu (iSAQB) ve profesyonel BT dergisi iX, 12 ve 13 Kasım'daki uluslararası konferansın mekanı olarak Berlin'i seçti. 11 ve 14 Kasım tarihlerinde konferans günlerinin öncesinde ve sonrasında başka atölye çalışmaları da gerçekleştirilecektir.
Konferans programı, 40 İngilizce ders ve dört açılış konuşması sunmaktadır:
- Üretken yapay zeka yazılım mimarisiyle buluşuyor
- Yapay zeka destekli yazılımlar için güvenli mimariler
- Geliştirici verimliliğini ölçebilir miyiz?
- Modern mimari çalışma: tanımdan niteliğe
- Güvenlik politikanızı denetlenebilir hale getirin
- Etki alanı odaklı dönüşüm: Eski sistemlerin yapısı nasıl geliştirilir?
(Ben)