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

Bir business süreci kâğıda dökülürken hep bir şeyler kayboluyor. Görüşmeler sürecin yalnızca tek bir kişiye görünen kısmını yakalıyor; o görüşmelerden yazılan requirement dokümanı da kimsenin söylemeyi akıl etmediği adımları atlıyor. Event Storming bu boşluğu bir workshop ile kapatır: business uzmanları ve developer’lar domain event’lerini kronolojik sırayla duvara dizer, süreç herkese aynı anda görünür hale gelene kadar.

Daha önce hiç oturum yönetmediysen Big Picture formatıyla başla ve business uzmanlarını baştan sona odada tut. Tekniğin sunduğu diğer her şey (detaylı süreç tasarımı, aggregate sınırları, servis sınırları) o ilk oturumun ürettiği ortak haritaya dayanır; domain uzmanı olmadan yapılan oturum ise developer’ların tahmin yürüttüğü bir tasarım toplantısına dönüşür.

Event Storming Nedir#

Event Storming, Alberto Brandolini tarafından oluşturulan ve business ile teknik insanları bir araya getirerek karmaşık domain’leri keşfetmeyi sağlayan bir workshop formatıdır. Temel fikir basit: sistemde olup biten şeyleri (domain event’lerini) yapışkan notlarla bir zaman çizelgesine dizersin. Grup buradan devam edip bu event’leri tetikleyen komutları, aktörleri ve business kurallarını çıkarır.

Bu teknik, Domain-Driven Design (DDD) topluluğundan çıkmış ve geleneksel modelleme yaklaşımlarına hafif bir alternatif sunmuştur. Resmi diyagramların ve uzun dokümanların yerini, renkli yapışkan notlarla kaplı uzun bir duvar alıyor. Görüşmeye dayalı requirement çalışmasından farkı şu: bütün grup aynı zaman çizelgesine aynı anda bakıyor ve onu birlikte düzenliyor.

Duvarın Ortaya Çıkardıkları#

İyi yönetilen bir oturum, karmaşık bir business sürecini 2-4 saatte haritalıyor. Aynı anlayışı görüşmelerden ve dokümanlardan toplamak haftalar sürüyor. Şartı şu: işin gerçekte nasıl yürüdüğünü bilen insanlar odada olacak.

Asıl kazanç, kimse sormadan ortaya çıkanlar. Business uzmanları zaman çizelgesini okurken boşlukları doldurmaya başlıyor: “Durun, ödeme başarısız olursa ne olur?” ya da “Aylık mutabakat sürecinden hiç bahsetmedik.” Süreç bir bütün olarak görünür hale gelince eksik parçalar kendiliğinden belli oluyor. Aynı etki, birbirini tutmayan zihinsel modelleri de yakalıyor. Marketing ekibinin “sipariş onaylandı” event’i duvarda engineering’in varsaydığından başka bir noktada duruyorsa, anlaşmazlık production’da değil workshop’ta çıkıyor.

İki yan etkiyi ayrıca yazmaya değer. Herkes aynı event isimlerinde birleşiyor; ubiquitous language (DDD’deki adıyla) sözlük toplantısı yapılmadan böyle kuruluyor. Bir de insanların artık fark etmez olduğu workaround’lar ve manuel adımlar, her birine ayrı bir yapışkan not gerektiği anda görünür hale geliyor.

Renk Kodlama Sistemi#

Event Storming, farklı yapışkan not türleri için belirli renkler kullanır. Renkler bir düşünme aracı işlevi görüyor: her biri domain’e dair farklı bir soru sorduruyor.

Renk	Ne tutar	Notlar
Turuncu	Domain event’leri, geçmiş zaman	OrderPlaced, PaymentProcessed, InventoryReserved. Business’ın önemsediği gerçekler.
Mavi	Komutlar, emir kipi	PlaceOrder, ProcessPayment, ReserveInventory. Bir aktör verir ya da bir policy tetikler.
Sarı	Aktörler ve persona’lar	Customer, Admin, PaymentGateway, CronJob. İnsan, sistem ya da zamana bağlı tetikleyici olabilir.
Lila	Policy’ler ve business kuralları	”OrderPlaced olduğunda, ReserveInventory yap.” Bir event’i bir sonraki komuta bağlar.
Pembe	Sorunlar ve açık sorular	”Ödeme 10 dakikadan fazla sürerse ne olur?” Yakala ve devam et; akışı durdurmasına izin verme.
Yeşil	Read model’ler ve view’lar	AvailableInventory, CustomerCreditLimit. Aktörün komut vermeden önce görmesi gereken veri.
Büyük sarı	Aggregate’ler ve bounded context’ler	Sonraki fazlarda eklenir. Aynı tutarlılık sınırını paylaşan event ve komut grupları.

Event Storming Türleri#

Tekniğin üç ana türü var. Kapsam, süre ve odada kimin bulunması gerektiği bakımından ayrışıyorlar.

Tür	Hedef	Süre	Kimler katılır	Çıktı
Big Picture	Tüm business domain’ini hızlıca anlamak	4-8 saat	Business uzmanları, developer’lar, product manager’lar	Tüm domain boyunca üst düzey event akışı
Process Modeling	Tek bir business sürecini detaylı tasarlamak	2-4 saat	O sürece odaklanan küçük grup	Tüm edge case’leri içeren detaylı süreç akışı
Software Design	Domain model’i mimariye çevirmek	2-4 saat	Çoğunlukla developer’lar, birkaç business uzmanı	Aggregate’ler, bounded context’ler, entegrasyon noktaları

Big Picture Event Storming#

Buradan başlarsın. Kapsam, müşteri kaydından sipariş karşılamaya ve aylık raporlamaya kadar business domain’inde olup biten her şey; derinlik ise diğer iki formatın işi.

İşleyiş sırası şöyle:

1. Domain event’leri kabaca kronolojik sırayla
2. Aktörler ve komutlar
3. Hotspot’lar (çok soru ya da karmaşıklık barındıran alanlar)
4. İlgili event’lerin subdomain’lere gruplanması

En çok yeni projeler ve legacy sistemler kazanıyor. Onboarding de öyle; bir satın alma ya da büyük bir entegrasyon öncesi yapılan keşif de, çünkü odadaki kimse henüz bütün resmi görmüş değil.

Process Modeling Event Storming#

Bu sefer tek bir süreci (“sipariş checkout”, “müşteri onboarding”) alıp derine iniyorsun. Burada her edge case ve her hata yolu önemli; basit görünen bir süreçte bile requirement’lara kimsenin yazmadığı durumlar neredeyse her zaman çıkıyor. Business kurallarını ve policy’leri ekliyor, aktörlerin hangi read model’lere ihtiyaç duyduğunu çıkarıyor, her hata için telafi edici aksiyonları haritalıyor ve tutarlılık sınırlarının nereye düştüğüne karar veriyorsun.

Software Design Event Storming#

Üç format içinde en teknik olanı bu ve domain’in ne yaptığını çoktan ortaya koymuş olan diğer ikisine yaslanıyor. Event’ler ve komutlar aggregate’lere gruplanır, bounded context’lerin sınırları çizilir, entegrasyon noktalarına anti-corruption layer konur, transaction scope’ları belirlenir.

Oturum Yönetimi#

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

Oturumdan Önce#

Yüz yüzede kısıt duvar uzunluğu: big picture oturumu için 5-10 metrelik boş bir yüzey gerekiyor ve üzerinde dikkat çekecek başka bir şey kalmamalı. Düşündüğünden fazla yapışkan not al, kalın marker getir; inceler iki adım geriden okunmuyor. Uzaktan çalışırken kısıt araçlar: dijital bir whiteboard (Miro, Mural ya da FigJam), önceden hazırlanmış renk kodlu board şablonu, katılımcılarla yapılan bir prova ve daha uzun bir takvim, çünkü uzaktan oturumlar daha yavaş ilerliyor.

Davet listesi ikisinden de önemli. İşlerin gerçekte nasıl yürüdüğünü bilen business uzmanlarına (nasıl yürümesi gerektiğini değil), sistemi inşa edecek developer’lara, bir product owner’a ve kapsamdaki alanların domain uzmanlarına ihtiyacın var. 6-12 kişiyi hedefle: daha azında perspektif kaçırıyorsun, daha çoğunda yönetmek zorlaşıyor. Öncesinde kısa bir not gönder: Event Storming nedir, neden yapıyorsunuz, katılımcı ne getirmeli. Oturumun keşifsel olduğunu ve henüz “doğru” bir cevap bulunmadığını açıkça yaz; yoksa insanlar bir tasarımı onaylamaya geldiklerini sanıyor.

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: insanlar çözümlere atlamak isteyecek. Bugün ne olduğunu sormaya devam et; yeniden tasarım, mevcut süreç duvara çıkana kadar bekleyebilir.

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, her kural için bir not. Tipik bir tanesi şöyle okunuyor: “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? Bir küme genellikle karmaşıklığı, başka bir sistemle entegrasyon noktasını ya da requirement’ların hiç netleşmediği bir yeri işaret ediyor. Bunların oturum içinde cevaplanması gerekmiyor. Önemli olan, daha derin bakılacak kümelerin sıralanmış bir listesiyle çıkmak.

Faz 5: Sonraki Adımlar (15 dakika)

Hangi süreçlerin daha derin modellemeye ihtiyacı olduğuna ve bulguları kimin yazacağına karar vererek kapatın, sonra bir sonraki oturumun tarihini belirleyin.

Oturumdan Sonra#

Kimse odadan çıkmadan duvarın birkaç açıdan yüksek çözünürlüklü fotoğrafını çek, çünkü oda toplandıktan sonra notlar yerinden düşüyor ve kayboluyor.

Sonra grubun keşfettiği workflow’ları, her birine bir sahip iliştirilmiş açık soruları, alınan kararları ve dikkat isteyen hotspot’ları yaz. Tam transkripsiyona girme. Değeri taşıyan şey konuşmanın kendisi; grup ilerledikten sonra her yapışkan notun kusursuz kaydı fazla bir şey katmıyor. Fotoğrafları ve özeti bir hafta içinde paylaş, derin dalışları oturum tazeyken takvime koy.

Uzaktan Event Storming#

Uzaktan oturumlar işe yarıyor, üç yerde ayar gerekiyor.

Board, duvarın istemediği bir hazırlık istiyor: zaman çizelgesi için frame’ler ya da bölümler, önceden renklendirilmiş yapışkan not paleti, sorular için bir parking lot alanı ve kimin nerede çalıştığının görülmesi için açık bırakılan cursor tracking.

Moderasyon daha belirgin hale geliyor. Sırayı kimin aldığını söyle, fazların zamanında bitmesi için yerleşik zamanlayıcıyı çalıştır, daha sık check-in yap (“Bu herkese mantıklı geliyor mu?”) ve katılamayanlar için oturumu kaydet. Molalar yüz yüzeye göre daha sık geliyor. Breakout room’lar küçük grup çalışması için işe yarıyor; yeter ki gruplar geri birleşsin ve herkes kendi notlarını sesli olarak anlatsın.

Bazı şeyler ise iyileşiyor. Sessiz beyin fırtınası uzaktan daha iyi çalışıyor, çünkü kimse duvarda yer sırası beklemiyor; pattern’ler board üzerinde tek tıkla çoğaltılabiliyor ve insanlar ayrı alanlarda asenkron çalışabiliyor. Kaybettiğin şey odadaki enerji ve duvarın yanında geçen ara konuşmalar.

Moderasyon Alışkanlıkları ve İsimlendirme Tuzakları#

Duvarı Akışta Tutmak#

Önce happy path’i kur, edge case’leri sonra ekle. “Ödeme gateway’i çökerse ne olur?” sorusuyla açılan bir oturum ana akışa hiç ulaşamıyor. Bunu yaparken gerçek senaryolar soyut olanlardan çok daha iyi iş görüyor: “dünkü #12345 numaralı sipariş” üzerine tartışılabilecek bir şey, “bir sipariş” değil.

Çatışma burada işe yarıyor. İki kişi aynı süreci farklı anlatıyorsa her iki versiyon da duvara çıkar, çünkü aradaki fark bilgidir. Pembe yapışkanlar açık sorular için aynı işi görüyor: soru, biri düzgünce bakabilene kadar duvarda park halinde kalıyor ve zaman çizelgesi ilerlemeye devam ediyor. Her faza bir zamanlayıcı da kur. İstersen uzatırsın; sınır, grubun event isimlerini mükemmelleştirmesini engelliyor. “OrderSubmitted” mi “OrderPlaced” mı henüz önemli değil, biri duvara çıkıyor ve isim sonradan değişebiliyor.

Oturumları batıran iki alışkanlık, erken implementation konuşması ve olmayan moderatör. “Kafka kullanacağız” ve “bu microservice olmalı” başka bir günün konuları; birinin de saati tutması, konuşmayı yönlendirmesi ve sessiz kalanları içeri çekmesi gerekiyor. O kişi aynı anda tam katılım gösteremiyor.

Event İsimleri Nerede Yanlış Gidiyor#

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.

Oturumun Karşılığını Verdiği Yerler#

En net durum yeni bir proje: ilk satır kod yazılmadan duvarda geçen birkaç saat, sonrasında haftalarca sürecek yeniden çalışmayı önlüyor. Hemen arkasından kimsenin tam olarak anlamadığı devralınmış sistem geliyor; en uzun süredir orada olanları davet et, zaman çizelgesi hiç yazıya dökülmemiş bilgiyi geri kursun. Yeni katılanlar için tek bir oturum, klasör dolusu dokümanı okumaktan çok daha hızlı sonuç veriyor; bu da domain oturmuş olsa bile onboarding’i oturum yapmak için iyi bir gerekçe haline getiriyor.

İki mimari karar da buna yaslanıyor. Servis sınırları duvardaki bounded context’leri ve aggregate’leri takip ediyor; dolayısıyla domain anlaşılmadan o çizgileri çizmek tahminden ibaret. Entegrasyon işi aynı problemin küçültülmüş hali: entegrasyon noktalarını karşı ekiple birlikte Event Storm yap, iki sistemin değiş tokuş etmesi gereken event listesiyle masadan kalkarsın.

Süreç yeniden tasarımının kendi sırası var. Önce mevcut durumu, sonra istenen durumu storm et; çünkü iki duvar arasındaki farklar değişikliğin asıl kapsamı.

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ışkan
class 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 mekanik değil. İsimler tipe dönüşürken revize ediliyor, birkaç event tek bir class’ta birleşiyor. Yine de kod yazmaya başladığın model, business’ın duvarda anlattığı model oluyor.

Varsayılan Ne Zaman Geçerli#

Big Picture varsayılanı, domain yabancı olduğu ve onu bilen insanları odaya toplayabildiğin sürece geçerli. Uzun bir duvar ve birkaç saat, 6-12 katılımcıyla birlikte, bir tur daha yazılı requirement toplamaktan çok daha ileri götürüyor.

Workflow zaten oturmuşsa ve herkesçe biliniyorsa, uygulama kayda değer kuralı olmayan bir CRUD ise ya da business uzmanları katılamıyorsa bu varsayılanı bir kenara bırak. Onlar olmadan duvar, odadaki kimsenin doğrulayamayacağı varsayımlarla doluyor ve yine tahmine dönüyorsun. İlk denemede oturumu tek bir süreçle sınırla ve o süreci her gün yürüten insanları davet et.

Kaynaklar#

• Alberto Brandolini - Introducing EventStorming (yeni sekmede açılır) - Event Storming’in yaratıcısı tarafından yazılan, Big Picture, Process Design ve Software Design formatlarını kapsayan temel kitap.
• EventStorming.com (yeni sekmede açılır) - Kaynaklar, makaleler ve topluluk bağlantılarıyla Alberto Brandolini’nin resmi Event Storming web sitesi.
• EventStorming Kitap Resmi Sayfası (yeni sekmede açılır) - 2013’ten bu yana metodoloji ve evrimi hakkında arka plan bilgisi içeren resmi kitap sayfası.
• Eric Evans DDD Referansı (yeni sekmede açılır) - Eric Evans’ın Domain-Driven Design kitabındaki tüm pattern’leri özetleyen ücretsiz referans kılavuzu; Event Storming’in kavramsal temeli.
• Domain-Driven Design Community (yeni sekmede açılır) - Eric Evans’ın orijinal kitabı için topluluk kaynağı; Event Storming’in içinde işlediği DDD bağlamını anlamak isteyenler için.