EventStorming dimana Menemukan Pemahaman Bersama Melalui Peristiwa

Salah satu tantangan terbesar dalam DDD bukanlah menulis kode,

melainkan menyatukan pemahaman antara orang-orang yang berbicara bahasa berbeda:

engineer, product manager, domain expert, dan stakeholder bisnis.

Setiap orang membawa perspektifnya sendiri:

• Engineer berpikir dalam entitas dan API,

• Product manager berpikir dalam fitur,

• Domain expert berpikir dalam proses dan peraturan bisnis.

Dan sering kali, perbedaan bahasa ini membuat diskusi berputar tanpa hasil.

Nah, EventStorming hadir untuk menjembatani semua itu.
Ini bukan teknik coding, tapi teknik berpikir dan berkolaborasi visual agar tim memahami domain dengan cara yang sama.

“EventStorming is a workshop-based method to explore complex domains by focusing on domain events.” — Vlad Khononov, Learning Domain-Driven Design (2022)

Apa Itu EventStorming?

Secara sederhana, EventStorming adalah cara memetakan alur bisnis dengan menulis peristiwa-peristiwa (event) yang terjadi di domain, biasanya di atas dinding atau papan besar dengan sticky notes berwarna.

Kata “Storming” di sini menggambarkan proses eksplorasi yang intens dan cepat, bukan diskusi formal yang kaku.
Tujuannya bukan langsung “mendesain arsitektur,” tapi mendapatkan pemahaman utuh tentang bagaimana domain bekerja dari perspektif semua pihak.

Kata kuncinya:
Semua orang bisa berkontribusi, semua ide valid, dan peristiwa (event) adalah bahasa pemersatu.

Kenapa EventStorming Penting dalam DDD

DDD berfokus pada pemahaman domain.
Tapi sering kali, pengetahuan domain tidak tertulis dengan rapi,
ia tersebar di kepala orang-orang, dokumen lama, atau asumsi tim.

EventStorming membantu:

1. Menyatukan semua stakeholder di satu ruangan (atau papan digital).

2. Menyingkap logika bisnis tersembunyi lewat diskusi natural.

3. Membentuk bahasa umum (ubiquitous language) dari kejadian nyata di domain.

4. Menemukan batas-batas alami (bounded contexts) berdasarkan pola peristiwa.

Dengan kata lain, EventStorming adalah cara tercepat untuk “menemukan domain model” sebelum menulis satu baris kode pun.

Prinsip Utama: Berpikir dalam “Event”

Daripada bertanya “entitas apa yang kita butuhkan?”, facilitator EventStorming akan memulai dengan pertanyaan sederhana: “Apa saja yang terjadi di domain ini?”

Setiap jawaban ditulis dalam format Domain Event, sesuatu yang terjadi di masa lalu dan relevan bagi bisnis.

Contohnya:

• OrderPlaced

• PaymentReceived

• ShipmentSent

• CustomerRegistered

Setiap event ditempel di dinding dari kiri ke kanan, menggambarkan urutan waktu.

Dari situ, perlahan terbentuk narasi: bagaimana proses bisnis berjalan, siapa yang terlibat, dan di mana kompleksitas muncul.

Warna dan Artefak Utama

EventStorming biasanya menggunakan sticky note dengan warna berbeda, yang masing-masing mewakili artefak penting dalam domain.

• Oranye: Artefak Domain Event

  • Artinya: Sesuatu yang terjadi di masa lalu

• Biru: Artefak Command

  • Artinya: Tindakan yang menyebabkan Event

• Kuning: Artefak External System / Policy

  • Artinya: Sistem atau aturan luar yang memicu tindakan

• Merah muda: Artefak Actor / User

  • Artinya: Siapa yang menjalankan command

• Hijau: Artefak View / Read Model

  • Artinya: Informasi yang dilihat pengguna

• Ungu: Artefak Aggregate / Entity

  • Artinya: Unit logika bisnis yang menangani command

Tidak semua workshop butuh semua warna. Fokusnya bukan estetika, tapi pemahaman bersama tentang hubungan sebab-akibat di domain.

Fase-Fase EventStorming

Menurut Khononov (2022), proses EventStorming umumnya terdiri dari beberapa tahap yang semakin mendalam.

1. Big Picture EventStorming

Tujuannya: menemukan alur bisnis secara keseluruhan.

Peserta dari berbagai fungsi (bisnis, teknis, operasional) diminta menuliskan semua event penting dalam proses.
Hasilnya sering kali berantakan — dan itu bagus! Karena di sanalah percakapan penting muncul.

Contoh:
Ketika seseorang menulis PaymentFailed, peserta lain mungkin bertanya,
“Lho, itu terjadi sebelum atau sesudah OrderCancelled?”
Diskusi seperti itu mengungkap aturan bisnis implisit yang selama ini tidak pernah terdokumentasi.

2. Process-Level EventStorming

Setelah gambaran besar terbentuk, tim bisa memperdalam satu proses spesifik, misalnya Order Fulfillment.
Di tahap ini, kita mulai melihat command, actor, dan aggregate yang terlibat.

Misalnya:

• Command: PlaceOrder

• Aggregate: Order

• Event: OrderPlaced

• Actor: Customer

Dan mungkin muncul insight seperti: “Kalau stok tidak cukup, event OrderRejected bisa muncul.”

Dari sini, kita mulai melihat pola bounded context dan logika bisnis yang nyata.

3. Design-Level EventStorming

Tahap ini paling teknis, dilakukan biasanya oleh engineer dan arsitek sistem.
Di sini, event dan command diterjemahkan ke dalam komponen desain seperti:

• Aggregate (logika domain utama)

• Saga / Process Manager (mengatur alur lintas aggregate)

• Read Model / Projection (untuk query data)

• External System Integration (pihak ketiga)

Contoh dalam Rust (sketsa sederhana):

struct Order {
    id: u64,
    status: OrderStatus,
}

impl Order {
    fn place(&mut self) -> OrderPlaced {
        self.status = OrderStatus::Placed;
        OrderPlaced { order_id: self.id }
    }
}

struct OrderPlaced {
    order_id: u64,
}

Dari event yang awalnya hanya sticky note oranye, kini kita bisa melihat kode yang berbicara dengan bahasa bisnis yang sama.

Temuan yang Sering Muncul dari EventStorming

EventStorming bukan hanya latihan pemetaan, ini adalah alat diagnosis organisasi.

Beberapa temuan umum:

• Ambiguitas istilah: orang berbeda menyebut hal yang sama dengan istilah berbeda.

• Kekosongan tanggung jawab: ada event tanpa command yang jelas.

• Masalah komunikasi antar tim: event muncul di satu context tapi dikonsumsi di context lain tanpa koordinasi.

• Aturan bisnis tersembunyi: “oh ternyata itu otomatis dibatalkan kalau lewat 24 jam!”

Setiap temuan seperti ini adalah pengetahuan domain baru, dan itulah nilai utama EventStorming.

Nilai Praktis bagi Engineer

Bagi engineer, EventStorming terasa seperti cheat code untuk memahami domain baru.

Alih-alih membaca dokumen setebal 50 halaman atau menebak-nebak lewat backlog Jira, kita bisa melihat alur bisnis hidup di depan mata.

Kita tahu:

• Event apa yang penting,

• Siapa yang memicunya,

• Kondisi apa yang menyebabkannya gagal,

• Dan bagaimana satu bounded context memengaruhi yang lain.

Setelah workshop, kode yang kita tulis jadi jauh lebih dekat dengan cara bisnis berpikir.

EventStorming dan Bounded Context

Salah satu hasil alami dari EventStorming adalah munculnya pola pemisahan alami antar bagian domain.

Ketika papan mulai “penuh”, kita bisa mulai melihat klaster event yang saling erat, itulah kandidat bounded context.

“Bounded contexts don’t come from architects — they emerge from understanding.” — Vlad Khononov, 2022

Bounded context yang ditemukan dengan cara ini jauh lebih realistis, karena tumbuh dari percakapan lintas tim, bukan dari diagram PowerPoint.

Kapan Menggunakan EventStorming

Gunakan EventStorming ketika:

• Tim baru akan memulai proyek besar,

• Domain masih kabur atau penuh asumsi,

• Ada ketegangan antar tim atau model yang tidak selaras,

• Atau ketika organisasi ingin membangun ubiquitous language.

Sebaliknya, untuk sistem kecil atau domain yang sudah stabil, EventStorming mungkin berlebihan, cukup gunakan diagram alur sederhana.

---

Tips Memfasilitasi EventStorming

1. Mulai dari event, bukan dari entitas.
   Jangan tanya “objek apa yang kita punya?”, tapi “apa yang terjadi?”

2. Dorong partisipasi semua pihak.
   Tidak ada jawaban salah. Justru ketidaksepakatan itu bahan diskusi.

3. Gunakan papan besar dan sticky notes.
   Visualisasi itu penting, otak manusia lebih cepat memahami pola.

4. Beri ruang untuk chaos.
   Di awal pasti berantakan, tapi dari kekacauan itu muncul struktur.

5. Akhiri dengan insight, bukan diagram sempurna.
   Tujuan utama: pemahaman bersama, bukan artefak yang rapi.

Ringkasnya, ini adalah Percakapan yang Mengubah Cara Berpikir

EventStorming bukan alat teknis, ia alat manusiawi.
Ia mengubah cara tim memahami domain dari debat tentang solusi menjadi percakapan tentang kejadian nyata.

Setelah workshop, semua orang, baik engineer, PM, maupun ahli bisnis, akan mulai berbicara dengan bahasa yang sama. Dan itu, dalam semangat DDD, adalah kemenangan terbesar.

“Software design is a communication game. EventStorming makes the rules visible.” — Vlad Khononov, Learning Domain-Driven Design (2022)

Referensi

Khononov, V. (2022). Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy. O’Reilly Media.