Event Storming: Mengurai Kompleksitas Bisnis dan Merancang Sistem Event-Driven yang Efektif

Dunia pengembangan software modern semakin kompleks. Kita dituntut untuk membangun sistem yang responsif, skalabel, dan mampu berevolusi dengan cepat mengikuti kebutuhan bisnis. Konsep seperti Event-Driven Architecture (EDA) dan Microservices Architecture telah menjadi pilihan populer untuk mencapai tujuan ini. Namun, merancang sistem semacam itu tidaklah mudah. Bagaimana kita bisa memastikan semua pihak—mulai dari tim bisnis hingga developer—memiliki pemahaman yang sama tentang bagaimana bisnis bekerja dan bagaimana sistem harus meresponsnya?

Di sinilah Event Storming hadir sebagai penyelamat. Ini adalah metode workshop kolaboratif yang visual dan cepat untuk menjelajahi domain bisnis yang kompleks dan merancang arsitektur sistem yang lebih baik, terutama untuk sistem event-driven. Bayangkan sebuah sesi di mana semua orang yang terlibat dalam sebuah proyek berkumpul di depan papan tulis besar, menempelkan sticky notes, dan secara bersama-sama memetakan alur peristiwa dalam bisnis mereka. Kedengarannya menarik, bukan?

Mari kita selami lebih dalam apa itu Event Storming, mengapa penting, dan bagaimana Anda bisa menerapkannya dalam proyek Anda.

1. Apa Itu Event Storming?

Event Storming adalah teknik workshop yang dirancang oleh Alberto Brandolini untuk mengeksplorasi domain bisnis yang kompleks dengan fokus pada domain events. Ini adalah pendekatan yang sangat visual dan kolaboratif, di mana peserta dari berbagai latar belakang (bisnis, developer, QA, dll.) bekerja bersama untuk memetakan “apa yang terjadi” dalam suatu sistem.

📌 Inti dari Event Storming: Mengidentifikasi peristiwa-peristiwa penting (events) yang terjadi dalam domain bisnis dan memahami urutan serta konsekuensi dari peristiwa tersebut.

Alih-alih memulai dengan data atau fungsionalitas, Event Storming dimulai dengan peristiwa (events) karena peristiwa adalah fakta yang tidak dapat disangkal dan merupakan bahasa umum yang dapat dipahami oleh semua orang. Misalnya, “Pesanan Dibuat”, “Pembayaran Diterima”, “Produk Dikirim”. Semua ini adalah fakta yang terjadi di masa lalu.

💡 Mengapa “Storming”? Kata “storming” mengacu pada brainstorming yang intens dan cepat. Tujuannya adalah untuk menghasilkan sebanyak mungkin ide dan pemahaman dalam waktu singkat, tanpa terlalu banyak filter di awal. Kesalahan dan miskonsepsi akan diperbaiki seiring berjalannya proses.

2. Mengapa Event Storming Penting untuk Developer?

Event Storming bukan sekadar teknik bisnis; ini adalah alat yang sangat ampuh bagi developer karena beberapa alasan kunci:

Memecah Kompleksitas Bisnis: Sistem modern sering kali berinteraksi dengan banyak entitas dan proses. Event Storming membantu kita melihat gambaran besar dan bagaimana berbagai bagian saling terhubung, memudahkan kita mengurai kompleksitas tersebut menjadi bagian-bagian yang lebih kecil dan mudah dikelola.
Memfasilitasi Komunikasi Lintas Tim: Ini adalah jembatan antara tim bisnis dan teknis. Dengan visualisasi bersama, asumsi tersembunyi dapat terungkap, dan kesepahaman bersama tentang domain akan terbangun. Tidak ada lagi “tim bisnis maunya apa sih?” atau “developer kok nggak ngerti-ngerti!”.
Membantu Identifikasi Bounded Contexts (DDD): Bagi Anda yang familiar dengan Domain-Driven Design (DDD), Event Storming adalah cara yang fantastis untuk secara alami menemukan bounded contexts—area-area dalam domain yang memiliki model dan bahasa sendiri. Ini adalah fondasi kuat untuk merancang microservices yang kohesif.
Dasar Kuat untuk EDA dan Microservices: Dengan mengidentifikasi events, commands, dan aggregates, kita mendapatkan peta jalan yang jelas untuk merancang sistem event-driven. Kita bisa melihat di mana event perlu dipublikasikan, layanan mana yang perlu mendengarkan event tersebut, dan bagaimana data mengalir antar microservices.
Mengurangi Asumsi dan Miskonsepsi: Seringkali, masalah dalam pengembangan muncul karena asumsi yang berbeda antara anggota tim. Event Storming memaksa semua orang untuk memvisualisasikan dan mendiskusikan proses, mengurangi ruang untuk salah tafsir.
Meningkatkan Kualitas Desain: Dengan pemahaman yang lebih dalam tentang domain, developer dapat membuat keputusan desain yang lebih tepat, menghasilkan arsitektur yang lebih fleksibel, tangguh, dan mudah dipelihara.

3. Perlengkapan dan Peran dalam Event Storming

Untuk mengadakan sesi Event Storming yang efektif, Anda memerlukan beberapa perlengkapan dan peran kunci:

Perlengkapan:

Papan Tulis atau Dinding Lebar: Semakin besar semakin baik. Ini adalah kanvas Anda.
Sticky Notes Berbagai Warna: Warna-warna ini akan memiliki makna spesifik.
- Oranye (Wajib): Domain Events
- Biru: Commands
- Kuning: Aggregates/Entities
- Ungu: External Systems
- Hijau: Policies/Reactions
- Merah Muda: Read Models/Projections (UI)
- Merah: Hotspots/Pain Points (area masalah/ketidakjelasan)
Spidol: Pastikan warnanya kontras dengan sticky notes.
Waktu: Alokasikan 2-4 jam untuk sesi awal (Big Picture).

Peran Kunci:

Fasilitator: Orang yang memandu sesi, menjaga fokus, dan memastikan semua orang berpartisipasi. Dia tidak ikut berdiskusi tentang domain, melainkan mengatur alur workshop.
Domain Experts: Orang yang paling tahu tentang bagaimana bisnis bekerja (misalnya, product owner, manajer operasional, sales). Mereka adalah sumber kebenaran utama.
Developer: Tim teknis yang akan membangun sistem. Mereka membawa perspektif teknis dan membantu menerjemahkan kebutuhan bisnis ke dalam desain sistem.
QA/Tester: Membantu mengidentifikasi skenario edge case dan potensi masalah.
UI/UX Designer: Membawa perspektif pengguna dan bagaimana informasi akan ditampilkan.

✅ Kunci sukses: Pastikan semua pihak yang relevan hadir dan berpartisipasi aktif. Semakin beragam sudut pandang, semakin kaya pemahaman yang didapat.

4. Langkah-Langkah Melakukan Event Storming (Workshop)

Ada beberapa level Event Storming, mulai dari gambaran besar hingga detail implementasi. Kita akan fokus pada Big Picture Event Storming yang paling umum dan fundamental.

A. Big Picture Event Storming (2-4 jam)

Tujuan: Mendapatkan pemahaman menyeluruh tentang seluruh domain bisnis, mengidentifikasi semua peristiwa penting, dan menemukan bounded contexts.

Siapkan Ruangan: Tempelkan kertas besar atau gunakan papan tulis yang sangat luas. Ini akan menjadi “garis waktu” Anda.
Identifikasi Domain Events (Sticky Note Oranye 🍊)
- Mulai dengan pertanyaan: “Apa yang terjadi dalam bisnis ini?”
- Tuliskan setiap peristiwa penting yang terjadi di masa lalu, selalu dalam bentuk past tense. Contoh: Pesanan Dibuat, Pembayaran Diterima, Produk Dikirim, Pengguna Terdaftar.
- Tempelkan secara kronologis di papan tulis. Jangan khawatir tentang akurasi kronologi di awal, perbaiki nanti. Fokus pada kuantitas.
- “No filter!”: Dorong semua orang untuk menempelkan ide sebanyak mungkin tanpa ragu atau takut salah.
Urutkan Kronologis dan Perbaiki Alur
- Setelah banyak events tertempel, fasilitator akan memandu peserta untuk mengurutkan events secara kronologis dari kiri ke kanan.
- Diskusikan dan perbaiki alur jika ada yang tidak masuk akal atau ada peristiwa yang terlewat.
Identifikasi Commands (Sticky Note Biru 🔵)
- Untuk setiap Domain Event, tanyakan: “Apa yang memicu peristiwa ini terjadi?”
- Ini biasanya adalah tindakan yang dilakukan oleh pengguna atau sistem lain. Contoh: Untuk Pesanan Dibuat, command-nya bisa Buat Pesanan.
- Tempelkan Command tepat sebelum Event yang dipicunya.
Identifikasi Aggregates/Entities (Sticky Note Kuning 🟡)
- Untuk setiap Command dan Event, tanyakan: “Objek bisnis (entitas) apa yang berubah atau terlibat?”
- Ini adalah “hal” yang memiliki identitas dan mengelola konsistensi data. Contoh: Pesanan, Produk, Pengguna.
- Tempelkan Aggregate di atas Command dan Event yang memengaruhinya. Ini akan mulai menunjukkan bounded contexts secara visual.
Identifikasi External Systems (Sticky Note Ungu 🟣)
- Tanyakan: “Sistem eksternal apa yang terlibat atau berinteraksi di sini?”
- Ini bisa berupa payment gateway, layanan email, CRM, atau API pihak ketiga lainnya.
- Tempelkan saat interaksi terjadi.
Identifikasi Policies/Reactions (Sticky Note Hijau 🟢)
- Tanyakan: “Ketika peristiwa ini terjadi, apa lagi yang harus dilakukan sistem secara otomatis?”
- Ini adalah aturan bisnis atau reaksi otomatis terhadap suatu event. Contoh: “Ketika Pesanan Dibuat, maka Kirim Email Konfirmasi.”
- Tempelkan setelah Event yang memicunya, dan panah ke Command berikutnya jika ada.
Identifikasi Read Models/Projections (Sticky Note Merah Muda 🌸)
- Tanyakan: “Informasi apa yang perlu ditampilkan kepada pengguna atau sistem lain pada titik ini?”
- Ini adalah tampilan data yang dioptimalkan untuk kebutuhan baca. Contoh: Daftar Pesanan Saya, Detail Produk.
- Tempelkan di bagian bawah, di mana data tersebut relevan untuk ditampilkan.
Identifikasi Hotspots/Pain Points (Sticky Note Merah 🔴)
- Selama proses, jika ada area yang membingungkan, tidak jelas, membutuhkan diskusi lebih lanjut, atau merupakan risiko bisnis/teknis, tandai dengan sticky note merah. Ini adalah area yang perlu ditindaklanjuti.

B. Proses Setelah Big Picture Event Storming

Setelah sesi Big Picture, Anda akan memiliki dinding penuh sticky notes yang merepresentasikan pemahaman bersama tentang domain Anda. Ini adalah artefak yang sangat berharga!

Identifikasi Bounded Contexts: Lingkari kumpulan events, commands, dan aggregates yang secara logis saling terkait dan membentuk sebuah unit fungsional. Ini adalah kandidat kuat untuk microservices Anda.
Diskusi Mendalam: Gunakan Hotspots Merah untuk memandu diskusi lebih lanjut atau sesi deep-dive yang lebih terfokus.
Dokumentasikan Hasil: Ambil foto, digitalisasi sticky notes (misalnya dengan Miro atau alat serupa), dan buat ringkasan.

5. Tips Praktis untuk Event Storming yang Efektif

🎯 Agar sesi Event Storming Anda sukses, perhatikan tips berikut:

Mulai dengan Pertanyaan Besar: Pastikan semua peserta tahu tujuan workshop. “Kita ingin memahami bagaimana proses pemesanan dari awal sampai akhir,” misalnya.
Jangan Takut Salah di Awal: Fokus pada kuantitas events di fase awal. Kualitas dan akurasi akan datang seiring diskusi.
Dorong Partisipasi Aktif: Pastikan semua orang merasa nyaman untuk berbicara dan menempelkan sticky notes. Fasilitator harus pandai memancing ide dari semua orang, terutama dari domain experts.
Fasilitator yang Baik Adalah Kunci: Fasilitator tidak boleh memihak atau mendominasi diskusi. Tugasnya adalah menjaga alur, waktu, dan memastikan semua orang didengar.
Dokumentasikan Hasil: Segera setelah sesi, foto papan tulis Anda dari berbagai sudut. Anda bisa menggunakan alat digital seperti Miro, Mural, atau bahkan aplikasi mobile untuk mendigitalisasi sticky notes.
Iterasi dan Perbaiki: Event Storming bukanlah aktivitas sekali jalan. Seiring waktu, pemahaman Anda bisa berkembang, dan Anda mungkin perlu melakukan sesi mini atau revisi.
Jaga Energi: Sesi bisa melelahkan. Sediakan istirahat singkat, minuman, dan makanan ringan. Putar musik latar jika sesuai.

❌ Hindari:

Terlalu banyak fokus pada detail implementasi di awal.
Hanya satu atau dua orang yang mendominasi sesi.
Melewatkan peran kunci (terutama domain experts).
Tidak ada fasilitator yang jelas.

Kesimpulan

Event Storming adalah investasi waktu yang sangat berharga bagi tim mana pun yang ingin membangun sistem yang solid, terutama dalam konteks arsitektur event-driven dan microservices. Dengan memvisualisasikan alur peristiwa bisnis secara kolaboratif, Anda tidak hanya mengurai kompleksitas tetapi juga membangun pemahaman bersama yang kuat di seluruh tim. Ini adalah fondasi yang akan mengurangi miskomunikasi, mempercepat pengembangan, dan menghasilkan desain sistem yang lebih tangguh dan adaptif.

Jadi, siapkan sticky notes Anda, kumpulkan tim, dan mulailah “badai” peristiwa Anda sendiri! Anda akan terkejut betapa banyak wawasan yang bisa Anda dapatkan.