Müşterilerime etki alanı odaklı tasarım (DDD) ve olay kaynağı bulma konusunda tavsiyelerde bulunduğumda, düzenli olarak ortaya çıkan bir an oluyor. Ekip kendinden emin, hatta belki biraz gururlu görünüyor. Bana diyorlar ki:
Duyurudan sonra devamını okuyun
“Aslında zaten etkinlikler üzerinde çalışıyoruz.”
Sonra bana etkinliklerini gösteriyorlar:
UserCreatedOrderUpdatedInvoiceDeleted
Ve içimde ürperiyorum.
Golo Roden, native web GmbH'nin kurucusu ve CTO'sudur. Olay odaklı ve hizmet tabanlı dağıtılmış mimarilere odaklanarak web ve bulut uygulamaları ile API'lerin tasarımı ve geliştirilmesiyle ilgilenmektedir. Yol gösterici ilkesi, yazılım geliştirmenin kendi başına bir amaç olmadığı, her zaman temeldeki profesyonelliği takip etmesi gerektiğidir.
Çünkü bunlar olaylar değil, yalnızca olay sözdizimine sahip klasik CRUD'lardır. Olayların dışsal biçimi vardır ama içsel anlambilimi yoktur. Ve bu fark, ne kadar ince görünse de, iş dilini konuşan bir sistem ile veritabanlarının dilini konuşan bir sistem arasındaki farktır.
Örnek: kurumsal basın yönetimi
Duyurudan sonra devamını okuyun
Kurumsal baskı yapan bir müşteriyi hayal edelim. Yazılım, büyük kuruluşlardaki binlerce yazıcıyı yönetir: hastaneler, üniversiteler ve şirket ofisleri. Yazıcıların sisteme eklenmesi, bakım için çevrimdışına alınması, duraklatılması, geri yüklenmesi ve son olarak devre dışı bırakıldıktan sonra kaldırılması gerekir.
Ekip, “olay odaklı sistem” adını verdikleri bir şey geliştirdi. Bunlar da onların olayları:
PrinterCreatedPrinterUpdatedPrinterDeleted
Hepsi bu. Üç olay. Bu tanıdık geliyor mu?
Bu kılık değiştirmiş CRUD. İsimler geliyor INSERT, UPDATE VE DELETE İLE Created, Updated VE Deleted değişti ama anlamsal yoksulluk aynı. eğer öyleysen PrinterUpdatedolay, ne biliyorsun? Bir şeyler değişti. Peki tam olarak ne değişti? Bunu yapmak için yüke bakmanız gerekir. Neden değişti? Hiçbir fikrim yok. Bu planlı bir bakım olayı mıydı yoksa beklenmedik bir arıza mıydı? Olay bunu ortaya koymuyor.
Cinayet sorunu
Ve bu bana her zaman biraz belirsiz (ve umarım ironi ortadadır) bir örneği hatırlatır: hadi düşünelim UserDeleted (ki bununla pratikte de düzenli olarak karşılaşıyorum).
Yüksek sesle ve bilinçli olarak şunu söyleyin: UserDeleted. Kullanıcının başarıyla suikasta kurban gittiği anlaşılıyor:
“Kullanıcı silindi.”
Eğer bu bir gerilim filmi olsaydı şimdiye kadar araştırmacılar not alıyor olurdu.
Ama muhtemelen kastedilen şuydu: AccountClosed. VEYA UserDeactivated. VEYA SubscriptionCancelled. Bunların her birinin farklı bir anlamı, farklı iş sonuçları ve farklı alt etkileri vardır. Ancak CRUD dili tüm bu zenginliği tek, biraz hastalıklı bir fiilde barındırıyor.
Bu sadece yanlış değil. Aktif olarak yanıltıcıdır. CRUD dili yalnızca bilgi sızdırmaz. Olayların polis raporu gibi görünmesini sağlayabilir.
Bakımla ilgili soru eksik
Yazıcılarımıza geri dönelim. Bir bakım teknisyeni yardım masasını arar:
“Üçüncü kattaki yazıcı çalışmıyor. Ne oldu?”
Destek çalışanı veritabanındaki mevcut durumu inceler:
{ "printerId": "printer-3f-01",
"status": "offline"
}
Tek gördüğü bu. Yazıcı çevrimdışı. Ama neden? Ne zaman çevrimdışı oldu? Bakım için manuel olarak çevrimdışına mı alındı yoksa beklenmeyen bir hata mı oluştu? Bu daha önce oldu mu? Kaç kez?
CRUD etkinlikleriyle çalışanın artık günlükleri incelemesi, zaman damgalarını ilişkilendirmesi ve belki de teknisyeni daha sonra tekrar araması gerekiyor. Aramayla geçirilen her dakika, para kaybı ve artan hayal kırıklığı anlamına gelir.
Bunlar anlamsal yoksulluğun gizli maliyetleridir: sadece bilgi kaybı değil, zaman kaybı, bağlam kaybı, sisteme olan güven kaybı.
Semantik alternatif
Gerçek olaylar nasıl olurdu? Gerçekte ne olduğunu yansıtan olaylar? Etki alanı dilinde mi?
PrinterAddedPrinterBecameOnlinePrinterPausedPrinterResumedPrinterWentOfflinePrinterRemoved
İnce ama önemli değişikliğe dikkat edin. Diyor ki PrinterAddedOlumsuz PrinterCreated. Neden? Çünkü yazıcı anlamlı bir şekilde “yaratılmamıştır”. Kimse veritabanına satır ekleyerek yazıcı oluşturamadı. Yazıcı zaten mevcuttu. Bir fabrikadan teslim edilen, kutuda duran fiziksel bir nesneydi. Olan şu ki, sisteme eklendi.
Created bir CRUD dilidir. Added tahakkümün dilidir. Fark önemlidir.
aynen Removed yerine Deleted: Yazıcı zarar görmemiştir. Muhtemelen bir yerlerdeki bir depoda, yeniden görevlendirilmeyi bekliyor. Bu sistemin yönetiminden uzaklaştırılmıştır. Olan bu. Olayın anlatması gereken buydu.
Tam hikaye
Şimdi destek çağrısını gerçek olaylarla tekrar oynayalım. Çalışan yazıcı geçmişini çağırır:
2026-01-15 09:00 PrinterAdded
2026-01-15 09:05 PrinterBecameOnline
2026-01-16 14:30 PrinterPaused { "reason": "scheduled maintenance" }
2026-01-16 16:00 PrinterResumed
2026-01-17 11:45 PrinterWentOffline { "reason": "paper jam detected" }
2026-01-17 12:00 PrinterBecameOnline
2026-01-18 09:22 PrinterWentOffline { "reason": "connection lost" }
Artık her şeyi görebilirsiniz:
- Bağlantı kesildiği için yazıcı bugün sabah 9:22'de çevrimdışı oldu.
- Bu, iki gün içindeki ikinci beklenmedik çevrimdışı olaydır.
- Dün kağıt sıkışması vardı, bugün bağlantı var.
- Bundan önce herhangi bir aksaklık yaşanmadan devam eden bir bakım molası planlanmıştı.
Sonuç olarak teknisyenin işleri körü körüne denemesi gerekmez. Kağıt tepsisini değil ağ bağlantısını kontrol etmesi gerektiğini biliyor. Bir model görüyor çünkü aynı sorun geçmişte diğer yazıcılarda da yaşanmıştı: Belki bu yazıcının ağ kartı çalışmıyordur.
Bu CRUD olaylarının sağlayamayacağı bir değerdir. Sadece “durum nedir” değil, “o noktaya nasıl geldi” ve “bu model bize ne anlatıyor”.
Doğal dil olarak olaylar
Bu daha temel bir şeye değiniyor. Önceki bir yazımda CRUD ile kimsenin hikaye anlatmadığını yazmıştım. “Kırmızı Başlıklı Kız oluşturuldu, sonra güncellendi, sonra Büyükanne silindi” demezsiniz. Bu çok saçma. Hikayeyi olaylar aracılığıyla anlatırsınız: ne oldu, hangi sırayla ve neden önemliydi.
DDD ile ilgili başka bir yazımda, alan odaklı tasarımın gereksiz derecede karmaşık hale getirildiğini savundum. İşin özü basit: “Tahakkümün dilini konuşun!” Ancak biz bu sadeliği kalıp katmanlarının ve jargonun altına gömdük.
Bağlantı şu: İyi olayları formüle edenler otomatik olarak alanın dilini konuşur. Yapamazsın PrinterPaused Duraklatmanın bu alanda çevrimdışı olmaktan, kaldırılmaktan farklı bir kavram olduğunu anlamadan yazmak. Olayları adlandırma eylemi sizi sektör uzmanlarıyla konuşmaya zorlar. “Bir yazıcı geçici olarak ancak kasıtlı olarak çalışmayı durdurduğunda ne dersiniz?” Bu soru alanın tam kalbine gidiyor.
Bu, DDD demeden DDD'dir. Toplama yok, sınırlı bağlam yok, korkutucu terminoloji yok. Sadece olup biteni yakalayan olaylar, şirket onlara ne ad veriyorsa öyle adlandırılıyor.
DDD'ye giden yol olaylardan geçer
Başka bir deyişle olay kaynağı, alan odaklı tasarım için bir katalizördür.
DDD'yi müşterilere açıklamak zordur. Terminoloji korkutucu. Kavramlar soyuttur. Pek çok geliştirici (ben de dahil) bir noktada DDD için “çok aptal” olduğunu ve teorinin bunaldığını hissetti.
Ancak olayları açıklamak kolaydır. Herkes olayları anlıyor. “Ne oldu?” dil var olduğundan beri insanların sorduğu bir sorudur. Ekiplerden etkinliklerini tam olarak adlandırmalarını istediğinizde doğal olarak DDD yapıyorlar. Alan adının dilini konuşmaya başlarsınız. Alan uzmanlarıyla görüşmelere başlarsınız. Veritabanı tabloları yerine gerçeği yansıtan sistemler kurmaya başlıyorlar.
Etkinliklerine ve her yere bakan herkes Created, Updated VE Deleted Görüyorsunuz, yalnızca etkinlik modelinizi geliştirmekle kalmıyor, aynı zamanda işinizde gerçekte neler olduğu hakkında bir konuşma başlatma fırsatınız da var. Yazıcı eklendiğinde buna ne denir? Bir kullanıcı ne zaman ayrılır? Bir sipariş iptal edilir, para iadesi yapılır veya itiraz edilirse ne olur?
Bu soruların yanıtları, alan adı hakkında herhangi bir örnek kataloğun sunabileceğinden daha fazlasını ortaya koymaktadır.
İşler nasıl devam edebilir?
Bu size tanıdık geliyorsa buradan başlayın: etkinliklerinize bakın! Bunları yüksek sesle okuyun! Bu, veritabanı operasyonlarına veya şirketinizde olup bitenlere benziyor mu?
DDD ve olay kaynağının ardındaki kavramları daha derinlemesine incelemek için, etki alanı odaklı tasarım ve olay kaynağına yönelik bu tanıtımlar temelleri açıklamaktadır.
Çünkü olaylar bir hikaye anlatmalı, polis raporu değil.
(Ben)
Bir yanıt yazın