Event Storming: Karmaşık Domain'leri Anlamak İçin Pratik Rehber

Özet#

Event Storming, ekiplerin karmaşık business domain'leri ve workflow'ları hızlıca anlamasına yardımcı olan işbirlikçi bir workshop tekniğidir. Bu rehber, Event Storming oturumlarını yönetmekten edindiğim pratik bilgileri paylaşıyor - ne olduğu, neden işe yaradığı, etkili oturumların nasıl yapılacağı ve ne zaman kullanılacağı konularında. Renk kodlama sistemini, pratikte işe yarayan yönetim tekniklerini ve hem yüz yüze hem de uzaktan oturumların nasıl yapılacağını öğreneceksin.

Event Storming Nedir#

Event Storming, Alberto Brandolini tarafından oluşturulan ve business ve teknik insanları bir araya getirerek karmaşık business domain'leri keşfetmeyi sağlayan bir workshop formatıdır. Orijinal olarak "Big Picture" event storming olarak adlandırılan bu format, zamanla çeşitli varyasyonlar geliştirdi. Temel fikir basittir: sisteminizde olup biten şeyleri (domain event'leri) bir zaman çizelgesine yapışkan notlarla haritalayın, ardından bu event'leri tetikleyen komutları, aktörleri ve business kurallarını işbirliği içinde keşfedin.

Bu teknik, Domain-Driven Design (DDD) topluluğundan ortaya çıkmış ve geleneksel modelleme yaklaşımlarına hafif bir alternatif sunmuştur. Resmi diyagramlar ve uzun dokümantasyon yerine, bir oda dolusu insan, uzun bir duvar ve bir sürü renkli yapışkan not elde ediyorsun. Big Picture formatı ile başladıktan sonra Process Modeling ve Software Design varyasyonları ortaya çıktı—her biri farklı derinlik ve hedeflere sahip.

Geleneksel requirement toplama yöntemlerinden farkı şurada:

• Görselleştirme: Her şey duvarda mekansal bir zaman çizelgesinde yer alır; boşluklar ve tutarsızlıklar hemen görünür hale gelir
• İşbirliği: Business uzmanları ve developer'lar gerçek zamanlı olarak birlikte çalışır
• Hız: Karmaşık domain'leri haftalar değil, saatler içinde modelleyebilirsin
• Ortak dil: Süreç doğal olarak ortak bir kelime dağarcığı oluşturur

Event Storming Neden İşe Yarar#

Event Storming'i geleneksel requirement oturumlarının kaçırdığı birkaç spesifik şekilde değerli buldum:

Daha Hızlı Domain Anlama: İyi yönetilen bir oturumda, karmaşık bir business süreci haftalar süren görüşmeler ve dokümantasyon yerine 2-4 saat içinde haritalanabilir. Anahtar nokta, odada doğru insanların bulunması - işin gerçekte nasıl yürüdüğünü bilen insanların.

Gizli Requirement'ların Ortaya Çıkması: Business uzmanları duvardaki zaman çizelgesini gördüklerinde, boşlukları fark ediyorlar. "Durun, ödeme başarısız olursa ne olur?" veya "Aylık mutabakat sürecinden bahsetmedik." Bu sorular doğal olarak ortaya çıkıyor çünkü görselleştirme eksik parçaları bariz hale getiriyor.

Ekip Uyumu: Developer'lar ve business insanları genellikle aynı sürecin farklı zihinsel modellerine sahiptir. Event Storming bu farkları hemen görünür kılar. Marketing ekibinin "sipariş onaylandı" event'i, engineering'in varsaydığından farklı bir noktada gerçekleştiğinde, bunu production'da değil workshop'ta öğreniyorsun.

Ortak Dil: Süreç doğal olarak bir ubiquitous language (DDD terimlerinde) oluşturur. Herkes aynı event isimlerini kullandığında ve ne anlama geldikleri konusunda hemfikir olduğunda, business ve teknoloji arasında genellikle var olan çeviri katmanından kaçınırsın.

Pratikte işe yarayan şeyler:

• Edge case'leri erken keşfediyorsun, halletmenin ucuz olduğu zamanda
• Business uzmanları duyulduklarını hissediyor çünkü bilgileri kelimenin tam anlamıyla duvarda
• Teknik borç, workaround'ları ve manuel adımları gördüğünde görünür hale geliyor
• Zaman çizelgesi, darboğazları ve otomasyon fırsatlarını ortaya çıkarıyor

Tekrar tekrar gördüğüm bir pattern: business uzmanları bildiklerini düşündüklerinden daha fazlasını biliyorlar. Workshop formatı, bu bilgiyi görüşmelerin yapmadığı bir şekilde dışsallaştırmalarına izin veriyor. Doğru moderasyon ile bu sessiz bilgi açığa çıkar ve dokümantasyona dönüşür. Big Picture ile başlayıp Process Modeling'e geçmek karmaşıklığı yönetilebilir tutar. 2-4 saatlik oturumlar optimal; daha uzun süreler yorulma ve azalan katılım getirir.

Renk Kodlama Sistemi#

Event Storming, farklı yapışkan not türleri için belirli renkler kullanır. Bu sadece estetik değil - renkler domain'in farklı yönleri hakkında düşünmene yardımcı oluyor:

Turuncu - Domain Event'leri (geçmiş zaman): Olan şeyler

• OrderPlaced, PaymentProcessed, InventoryReserved
• Bunlar business'ın önemsediği gerçekler
• Her zaman geçmiş zamanda yazılır

Mavi - Komutlar (emir kipi): Event'lere neden olan aksiyonlar

• PlaceOrder, ProcessPayment, ReserveInventory
• Genellikle aktörler veya diğer event'ler tarafından tetiklenir
• Eylem olarak yazılır

Sarı - Aktörler/Persona'lar: Komutları kim veya ne tetikler

• Customer, Admin, PaymentGateway, CronJob
• İnsanlar, sistemler veya zamana dayalı tetikleyiciler olabilir

Lila/Mor - Policy'ler/Business Kuralları: Otomatik tepkiler

• "OrderPlaced olduğunda, ReserveInventory yap"
• Bunlar kodunda event handler'lar olur
• Event'leri komutlara bağlar

Pembe - Sorunlar/Sorular: Daha sonra çözülecek şeyler

• "Ödeme 10 dakikadan fazla sürerse ne olur?"
• "Kısmi iadeleri halletmemiz gerekiyor mu?"
• Bunların akışı engellemesine izin verme - yakala ve devam et

Yeşil - Read Model'ler/View'lar: Karar vermek için gereken bilgi

• AvailableInventory, CustomerCreditLimit
• Aktörlerin komut vermeden önce görmesi gereken veri nedir?

Büyük Sarı - Aggregate'ler/Bounded Context'ler (sonraki fazlar)

• İlgili event'lerin ve komutların grupları
• Sistemindeki doğal tutarlılık sınırları; bunlar Software Design oturumunda microservice sınırlarına dönüşür. Renk tutarlılığı ekip genelinde aynı dili konuşmayı sağlar.

Event Storming Türleri#

Her biri farklı hedeflere ve detay seviyelerine sahip üç ana tür vardır:

Big Picture Event Storming#

Hedef: Tüm business domain'i hızlıca anlamak Süre: 4-8 saat Katılımcılar: Geniş yelpaze - business uzmanları, developer'lar, product manager'lar Çıktı: Tüm domain boyunca üst düzey event akışı

Buradan başlarsın. Business domain'inizde olan her şeyi haritalıyorsun, müşteri kaydından sipariş karşılanmasına, aylık raporlamaya kadar. Odak noktası derinlik değil, genişliktir.

Ne yapmalısın:

1. Domain event'lerini kabaca kronolojik sırayla başlat
2. Aktörleri ve komutları ekle
3. Hotspot'ları belirle (çok fazla soru veya karmaşıklığa sahip alanlar)
4. İlgili event'leri subdomain'lere grupla
5. Henüz detaylara dalma - üst düzeyde kal

Bunun iyi çalıştığını gördüm:

• Yeni bir proje veya ürün başlatırken
• Yeni ekip üyelerini onboarding yaparken
• Kimsenin tam olarak anlamadığı bir legacy sistemi anlamaya çalışırken
• Potansiyel bir satın alma veya entegrasyonu keşfederken

Process Modeling Event Storming#

Hedef: Belirli bir business sürecini detaylı olarak tasarlamak Süre: 2-4 saat Katılımcılar: Bir sürece odaklanan daha küçük grup Çıktı: Tüm edge case'leri içeren detaylı süreç akışı

Big picture oturumundan sonra, belirli bir süreci ("sipariş checkout" veya "müşteri onboarding" gibi) alıp derine iniyorsun. Artık her edge case'i, her validasyon'ı, her hata senaryosunu önemsiyorsun.

Ne yapmalısın:

1. Big picture'dan bir süreç al
2. Tüm business kurallarını ve policy'leri ekle
3. Gereken tüm read model'leri belirle
4. Hata senaryolarını ve telafi edici aksiyonları haritalandır
5. Sınırları ve tutarlılık gereksinimlerini tanımla

"Basit" süreçlerin requirement'larda kimsenin bahsetmediği 15 edge case'e sahip olduğunu keşfettiğin yer burasıdır.

Software Design Event Storming#

Hedef: Domain model'i yazılım mimarisine çevirmek Süre: 2-4 saat Katılımcılar: Çoğunlukla developer'lar, bazı business uzmanları Çıktı: Aggregate'ler, bounded context'ler, entegrasyon noktaları

Bu en teknik türdür. Process modeling oturumunda keşfettiğin şeyleri nasıl implement edeceğine karar veriyorsun.

Ne yapmalısın:

1. Event'leri ve komutları aggregate'lere grupla
2. Bounded context'leri ve sınırlarını tanımla
3. Entegrasyon noktalarını ve anti-corruption layer'ları belirle
4. Context'ler arasındaki event akışlarını haritalandır
5. Tutarlılık sınırları ve transaction scope'ları belirle

Ekiplerle çalışmak bana big picture veya process modeling olmadan doğrudan bu faza atlamanın genellikle kötü sonuçlandığını öğretti. Önce domain anlayışına ihtiyacın var.

Event Storming Oturumu Nasıl Yönetilir#

Pratikte işe yarayan adım adım bir yaklaşım:

Oturumdan Önce#

1. Mekanı Hazırla

Yüz yüze için:

• Bulabildiğin en uzun duvarı bul (big picture oturumu için 5-10 metreye ihtiyacın olacak)
• Doğru renklerde çok fazla yapışkan not al (düşündüğünden fazlasını satın al)
• Kalın marker'lar getir (inceler uzaktan okunması zor)
• Duvarı temizle - dikkat çekmek için başka bir şey istemezsin

Uzaktan için:

• Dijital bir whiteboard kullan (Miro, Mural veya FigJam iyi çalışır)
• Renk kodlu yapışkan not alanları ile board şablonu hazırla
• Araçları katılımcılarla önceden test et
• Daha uzun oturumlar planla (uzaktan daha yavaştır)

2. Doğru İnsanları Davet Et

İhtiyacın olanlar:

• İşlerin gerçekte nasıl yürüdüğünü bilen business uzmanları (nasıl yürümesi gerektiğini değil)
• Sistemi inşa edecek developer'lar
• Product owner veya manager
• Belirli alanlar için domain uzmanları

6-12 kişiyi hedefle. Daha az olursa perspektif kaçırırsın. Daha çok olursa yönetim zorlaşır.

3. Beklentileri Ayarla

Önceden kısa bir açıklama gönder:

• Event Storming nedir
• Neden yapıyorsunuz
• Katılımcıların ne getirmesi gerektiği (domain bilgisi, sorular)
• Bunun keşifsel olduğu - henüz "doğru" bir cevap yok

Oturum Sırasında#

Faz 1: Domain Event'leri (45-60 dakika)

Bu talimatla başla: "Event'leri yazın - domain'imizde olan ve business'ın önemsediği şeyler. Geçmiş zaman kullanın. Kabaca kronolojik sırayla duvara yapıştırın."

İnsanların önce 10-15 dakika sessizce çalışmasına izin ver. Bu hızlıca çok sayıda event üretir ve bir kişinin domine etmesini önler.

Sonra zaman çizelgesini birlikte gözden geçirin. Giderken:

• Yinelenen event'leri grupla
• Belirsiz isimleri netleştir
• Tartışma - anlaşmazlık varsa, her iki versiyonu da koy
• Ortaya çıkan sorular için pembe yapışkan kullan

Yaygın sorun: İnsanlar çözümlere atlamak isteyecek. Onları "ne olur" a geri getir, "ne olmalı" ya değil.

Faz 2: Komutlar ve Aktörler (30-45 dakika)

Şimdi her event'ten önce komutlar için mavi yapışkanlar ekle: "Bu event'in olmasına ne neden oldu?"

Aktörler için sarı yapışkanlar ekle: "Bu komutu kim veya ne tetikledi?"

Model burada gerçek hissetmeye başlar. Pattern'lerin ortaya çıktığını göreceksin:

• Harici aktörler (müşteriler, partnerler)
• Dahili aktörler (adminler, destek personeli)
• Sistem aktörleri (scheduler'lar, entegrasyonlar)

Faz 3: Policy'ler ve Business Kuralları (30-45 dakika)

Otomatik tepkileri ara: "X olduğunda, Y olmalı."

Event'leri komutlara bağlamak için lila yapışkanlar kullan. Bunlar event handler'ların, business mantığının, otomasyon fırsatlarının.

Örnek: "PaymentReceived olduğunda, SendConfirmationEmail ve UpdateInventory yap"

Faz 4: Sorular ve Hotspot'lar (20-30 dakika)

Geri çekil ve duvara bak. Pembe yapışkan kümeleri nerede? İnsanların en çok sorusu nerede?

Bu hotspot'lar:

• Odaklanman gereken karmaşıklık alanları
• Mevcut anlayışındaki boşluklar
• Diğer sistemlerle entegrasyon noktaları
• Requirement'ların belirsiz olduğu yerler

Şimdi her şeyi cevaplamaya çalışma. Daha derine keşfetmek için önceliklendirin.

Faz 5: Sonraki Adımlar (15 dakika)

Grup olarak karar verin:

• Hangi süreçlerin daha derin modellemeye ihtiyacı var
• Bulguları kim dokümante edecek
• Hangi sorular araştırma gerektiriyor
• Ne zaman tekrar toplanacak

Oturumdan Sonra#

Fotoğraf Çek: Tüm duvarın birden fazla açıdan yüksek çözünürlüklü fotoğraflarını al. Yapışkan notlar düşecek, kaybolacak veya solacak.

Ana Çıkarımları Dokümante Et: Yaz:

• Keşfedilen ana workflow'lar
• Açık sorular ve sahipleri
• Alınan kararlar
• Dikkat gerektiren hotspot'lar

Her Şeyi Transkribe Etme: Değer olan konuşmadır, her yapışkan notun mükemmel bir kaydına sahip olmak değil.

Takip Et: Bir hafta içinde fotoğrafları ve özeti paylaş. Belirli süreçlerde daha derin dalmalar için toplantı planla.

Uzaktan Event Storming#

Uzaktan oturumlar işe yarar, ama ayarlamalar gerektirir:

Araç Kurulumu

• Zaman çizelgesini organize etmek için frame'ler veya bölümler kullan
• Önceden renklendirilmiş yapışkan not şablonlarının bir paleti oluştur
• Sorular ve sorunlar için bir parking lot alanı aç
• İnsanların başkalarının ne yaptığını görebilmesi için gerçek zamanlı cursor tracking'i etkinleştir

Yönetim Ayarlamaları

• Konuşma sırasının kimin olduğu konusunda daha açık ol
• Fazları ilerletmek için zamanlayıcı özelliğini kullan
• Daha sık check-in'ler yap ("Bu herkese mantıklı geliyor mu?")
• Katılamayanlar için mümkünse oturumu kaydet

Katılım Teknikleri

• Küçük grup çalışması için breakout room'lar kullan, sonra tekrar birleş
• Herkesin yapışkan notlarını sözlü olarak anlatmasını sağla
• Konsensus oluşturmak için oylama/reaksiyonları kullan
• Daha sık molalar ver (uzaktan yorgunluk gerçektir)

Farklı Çalışan Şeyler

• Sessiz beyin fırtınası uzaktan daha iyi çalışır (duvar alanı sınırlaması yok)
• Pattern'leri board'da kolayca kopyalayabilir/çoğaltabilirsin
• İnsanlar farklı alanlarda asenkron çalışabilir
• Ama enerji ve spontane konuşmanın bir kısmını kaybediyorsun

Uzaktan oturumların aynı kapsam için yüz yüze oturumlara göre yaklaşık %30 daha fazla zamana ihtiyaç duyduğunu gördüm.

Yaygın Pattern'ler ve Tuzaklar#

İşe Yarayan Şeyler#

Happy Path ile Başla: Önce ana akışı kur, sonra edge case'leri ekle. "Ödeme gateway'i çökerse ne olur?" ile başlarsan, asla bitmez.

Gerçek Örnekler Kullan: Soyut event'ler yerine, gerçek business senaryoları kullan. "Dünkü #12345 numaralı sipariş" "bir sipariş" ten daha somuttur.

Çatışmaları Kucakla: İki kişi aynı sürecin farklı görüşlerine sahip olduğunda, her ikisini de duvara koy. Farklar değerli bilgidir.

Yakala, Çözme: Sorular için pembe yapışkanlar sorunları yakalamak içindir, o anda çözmek için değil. İlerlemeye devam et.

Fazları Timebox'la: Her faz için bir zamanlayıcı ayarla. Her zaman uzatabilirsin, ama bir zaman limiti olması işleri ilerletiyor.

İşe Yaramayan Şeyler#

Analiz Felci: Her event ismini mükemmelleştirmeye çalışma. "OrderSubmitted" vs "OrderPlaced" henüz önemli değil. Birini seç, devam et, gerekirse sonra refactor et.

Erken Implementation Konuşmaları: Konuşmayı başlangıçta business seviyesinde tut. "Kafka kullanacağız" veya "Bu microservice olmalı" bekleyebilir.

Big Picture'ı Atlamak: Ekipler hemen detaylı process modeling'e dalmak ister. Direnmek. Önce context'e ihtiyacın var.

Business Uzmanlarını Dahil Etmemek: Sadece developer'larla bir Event Storming oturumu sadece bir design oturumdur. Domain'i bilen insanlara ihtiyacın var.

Yönetici Yok: Birinin sürece sahip olması, zamanı tutması, konuşmaları yönlendirmesi ve herkesin katılımını sağlaması gerekiyor. Aynı anda hem yönetmeye hem de tam katılmaya çalışma.

Tipik Tuzaklar#

Event Granülaritesi: "OrderProcessed" bir event mi yoksa altı mı? Duruma göre değişir. Business her adımı ayrı ayrı önemsiyorsa, böl. Sadece sonucu önemsiyorlarsa, bir olarak tut.

CRUD vs Event'ler: "OrderUpdated" genellikle iyi bir domain event değildir. Gerçekte ne değişti? "ShippingAddressChanged", "OrderCancelled" - bunlar anlamlı event'lerdir.

Teknik Event'ler: "EmailQueued" veya "CacheInvalidated" gibi teknik event'leri dahil etme konusunda dikkatli ol. Önce business event'lerine odaklan. Teknik event'ler software design oturumlarında daha sonra gelir.

Geçmiş vs Gelecek: Event'ler geçmiş zamandır (zaten oldu). Komutlar emir kipidir (yap). Bu ayrım model'i net tutar.

Event Storming Ne Zaman Kullanılır#

Event Storming özellikle bu senaryolarda faydalıdır:

Yeni Bir Proje Başlatmak: Kod yazmadan önce, domain'i anla. İyi bir Event Storming oturumu haftalarca yeniden çalışmayı kurtarabilir.

Legacy Sistem Anlama: Kimsenin tam olarak anlamadığı bir sistemi devraldığında, Event Storming bu bilgiyi yeniden inşa etmeye yardımcı olur. En uzun süredir orada olanları davet et.

Ekip Onboarding: Yeni ekip üyeleri dokümantasyon okumaktan çok bir Event Storming oturumuna katılarak çok daha hızlı işe alışır.

Süreç Yeniden Tasarımı: Business bir şeyin nasıl çalıştığını değiştirmek istediğinde, önce mevcut durumu Event Storm yap, sonra istenen durumu.

Microservice Sınırları: Keşfettiğin bounded context'ler ve aggregate'ler doğal olarak servis sınırlarını önerir. Önce domain'i anlamadan microservice çizgileri çizme.

Entegrasyon Planlaması: Başka bir sistem veya ekiple entegre olman gerektiğinde, hangi event'leri değiş tokuş etmen gerektiğini anlamak için entegrasyon noktalarını Event Storm yap.

Ne Zaman Kullanmamak:

• Açık workflow'lara sahip basit CRUD uygulamalar
• Business uzmanlarını odaya alamadığında (sadece tahmin edeceksin)
• İyi anlaşılmış, stabil domain'lere sahip projeler (onboarding hariç)
• Hangi problemi çözdüğünüzü bile bilmeden çok erken keşif

Yapışkan Notlardan Koda#

Event Storming artifakt'ları implementation'a nasıl map edilir:

Domain Event'ler → Event Class'ları

// Turuncu yapışkan not: "OrderPlaced"interface OrderPlacedEvent {  eventId: string;  orderId: string;  customerId: string;  items: OrderItem[];  totalAmount: number;  placedAt: Date;}

Komutlar → Command Handler'lar

// Mavi yapışkan not: "PlaceOrder"class PlaceOrderCommand {  constructor(    public customerId: string,    public items: OrderItem[],  ) {}}
class OrderCommandHandler {  async handle(command: PlaceOrderCommand): Promise<OrderPlacedEvent> {    // Komutu validate et    // Business kurallarını uygula    // Event oluştur    // Persist et ve publish et  }}

Policy'ler → Event Handler'lar

// Lila yapışkan not: "OrderPlaced olduğunda, ReserveInventory yap"class InventoryPolicy {  @EventHandler(OrderPlacedEvent)  async onOrderPlaced(event: OrderPlacedEvent): Promise<void> {    const command = new ReserveInventoryCommand(      event.orderId,      event.items    );    await this.commandBus.send(command);  }}

Aggregate'ler → Aggregate Root Class'ları

// Order ile ilgili event'leri gruplayan büyük sarı yapışkanclass Order {  private id: string;  private status: OrderStatus;  private items: OrderItem[];
  place(customerId: string, items: OrderItem[]): OrderPlacedEvent {    // Business mantığı    // Validate et    // Event oluştur  }
  cancel(reason: string): OrderCancelledEvent {    if (this.status === 'shipped') {      throw new Error('Gönderilmiş siparişi iptal edemezsin');    }    // Event oluştur  }}

Bu eşleme otomatik değil, ama Event Storming sana business'ın gerçekte nasıl çalıştığına dayalı bir domain model'i için avantaj sağlıyor.

Sonuç#

Event Storming basit görünen ama iyi yönetmek için pratik gerektiren tekniklerden biridir. Temel içgörü—insanları görsel bir zaman çizelgesi etrafında bir araya getirmenin anlamayı hızlandırdığı—farklı domain'lerde ve ekip yapılarında geçerliliğini koruyor. İlk oturumda mükemmellik beklemek gereksiz; hatalı bir workshop bile domain hakkında değerli bilgiler verecektir.

Pratikte işe yarayan şeyler:

• Detaylara dalmadan önce big picture ile başla
• Business uzmanlarını boyunca dahil et
• Renk kodlama sistemini tutarlı kullan
• Momentum'u korumak için fazları timebox'la
• Her soruyu o anda çözmeye çalışma
• İyi fotoğraflar çek ve ana çıkarımları hızlıca dokümante et

Gerçek değer duvardaki yapışkan notlar değil. Business ve teknik insanlar bir domain'i birlikte keşfettiklerinde gelişen ortak anlayıştır. Bu ortak anlayış daha iyi tasarım kararlarında, daha az yanlış anlamada ve business'ın gerçekte nasıl çalıştığını yansıtan kodda ortaya çıkıyor.

İlk Event Storming oturumunu planlıyorsan, küçük başla. Bir süreç seç, doğru insanları topla, materyalleri hazırla ve konuşmayı yönet. Teknik affedicidir - kusurlu bir oturum bile domain'in hakkında değerli bir şeyler öğretecektir.

Ek Kaynaklar#

• Alberto Brandolini'nin Kitabı: "Introducing EventStorming"
• EventStorming.com - Resmi website ve kaynaklar
• Awesome EventStorming - Curated kaynak listesi
• İlgili mimari pattern'ler için Domain-Driven Design konseptleri yazımıza bakabilirsin