Event Storming: Etkili ve eğlenceli bir domain modelleme aktivitesi
Büyük bir düşünür şöyle demiş:
The critical complexity of most software projects is in understanding the domain itself.
— Eric Evans
Yani diyor ki, yazılım projelerinde, teknik çözüm geliştirme faaliyeti başlı başına karmaşık bir süreçtir ancak bu süreci sağlıklı bir şekilde tamamlamanın yolu sadece teknik karmaşıklığı ortadan kaldırmaktan değil, daha çok işi, iş süreçlerini, işin terminolojisini doğru anlamaktan geçer. Zaten doğru anlaşılamayan bir soruna getirilen teknik çözümlerin uzun ömürlü olmadığını, uzun vadede kolaylık sağlamaktan çok, başa bela olduğunu birçoğumuz tecrübe etmişizdir. Kaçınız gelişimine katkıda bulunduğunuz bir proje için, “Keşke şurasını tekrar yazabilsek, burasını şuna dönüştürebilsek” şeklinde hasretle iç geçirmiştir?
Peki sorun nerede? Neden iş süreçlerindeki bu karmaşıklığın içinden çıkmak bu kadar çok çaba gerektiriyor?
Eric Evans, kitabında neredeyse takıntı diyebileceğimiz bir seviyede Ubiquitous Language (Ortak Dil) kavramından söz eder. Domain uzmanları (iş hayatını çözüm geliştirmeyi hedeflediğimiz kapsam içinde geçiren kişiler, yani işin sahipleri) ve teknik uzmanlar (çözümü geliştirmeyi hedefleyen kişiler, yani programcılar) arasında kullanılacak olan ve her iki tarafın da anlayabileceği bir dildir bu ve genellikle teknik insanların kendilerini, rahat hissettikleri doğal ortamdan biraz dışarı çıkmaya zorlamasıyla ulaşılabilecek bir durumdur. Domain uzmanına C#, MVC, Entity Framework öğretmek mi daha kolaydır, yoksa domain uzmanı Müşteri dediğinde teknik insanların gözlerinin önüne ilişkisel bir tablo ve kolonlarını getirmek yerine Müşteri denen şeyi bir varlık olarak kabul etmesi mi? :-)
Ortak dili konuşabilmek için bir çok araç var elimizin altında. UML, BPMN vb. gibi. Ancak iş insanlarının genellikle teknik insanlar olmadıklarını düşünürsek her zaman bu dillere ait diyagramları anlamalarını beklemek pek de mantıklı olmayacaktır, kaldı ki teknik bir adam olmama rağmen benim de anlayamadığım diyagramlar oluyor :-) Tüm iş süreçlerinin sadece UML ya da başka bir modelleme dili ile modellenmesi de bazen çok fazla çaba gerektiren ancak bu çabanın hak ettiği sonucu vermeyen, zamanla unutulup giden bir çalışmaya da dönüşebiliyor. İçinde yüzlerce sınıf bulunan bir UML diyagramı anlaşılması zor bir resme dönüşebiliyor, modellerin tüm davranışlarını tek bir diyagram üzerinde görmek mümkün olmayabiliyor.
Son zamanlarda popüler olan (ilk uygulaması yakın bir zamanda Alberto Brandolini tarafından yapılmış) Event Storming (ES), yukarıda bahsettiğim zorluklara güzel bir yanıt olarak karşımıza çıkıyor. Brandolini, inovasyonu teşvik etmek için bir yöntem olarak kullanılan Game Storming tekniği ile Domain-Driven Design prensiplerini çakıştırmış ve ortaya böyle etkili bir yöntem çıkarmış. İsimdeki “Storming” ifadesi her ne kadar brainstorming faaliyetini çağrıştırsa da, aslında brainstorming’den farklı bir çalışmadan söz ediyoruz. Çalışmayı yaparken amacımız yeni fikirler ortaya atmak ve bunun için beyinlerimizi zorlamak değil, modellemeye çalıştığımız domain’i daha iyi öğrenmek.
Ortak bir dilden söz etmiştik. ES ortak dil oluşturabilmek için etkili yöntemlerden biri. Ortak dil oluşturma yolunda, aynı zamanda ortak öğrenmeyi de gayet eğlenceli bir şekilde desteklediğini de söylemeliyim.
Peki nasıl uyguluyoruz bu çalışmayı?
İhtiyaçlar şunlar:
- Bol bol post-it (turuncu, pembe, mavi, yeşil, mor ve sarı. Ne anlama geldiklerini az sonra açıklayacağım)
- Boş ve uzun bir duvar
- İş insanları (domain uzmanları)
- Geliştiriciler
- Analistler
Domain Event’leri ile başlıyoruz
Tüm bu malzemeleri bir odaya dolduruyoruz ve domain uzmanlarına turuncu post-it ve kalemleri verip her bir post-it’in üzerine geçmiş zaman kipinde akıllarına gelen domain event’lerini yazmalarını istiyoruz. Hemen ardından, ne demek istediğimizi kimse anlamadığı için domain event’in ne olduğuna dair bir örnek vererek ilk post-it’i tahtaya yapıştırıyoruz:
Böylece domain event dediğimiz şeyin, bir işin gerçekleştirilmesi sırasında ortaya çıkan ve domain uzmanlarının ilgi alanına giren olaylar olduğunu göstermiş oluyoruz. Bu ilk post-it’ten sonra diğer domain event’leri de duvarda hızlı bir şekilde yerini almaya başlıyor.
Fark ettiğiniz üzere, post-it üzerinde bu event’i tetikleyen kaynağın ne olduğuna dair bir bilgi yok. Olayları çıkarma aşamasında olay kaynağı olan aktörlere dair bir gösterime girmiyoruz. Bir sonraki aşamada aktörlerin kimler/neler olduğunu da göstermeye başlayacağız.
Post-it’leri yapıştırdığımız alanı soldan sağa doğru zaman akışı içerisinde arka arkaya gelen event’lerle dolduruyoruz. Bu yaptığımız şeyin en güzel yanı diğer modelleme dillerinde olduğu gibi belli kurallara uymak zorunda olmamamız. Örneğin, bir event’i yapıştırdık ancak bu event’in detayı hakkında hiçbir bilgimiz yok. Belki o sırada işin uzmanı yanımızda değil, ya da manuel ilerleyen bir süreç var ve net olarak akışa hakim değiliz. Bu durumda pembe bir post-it ile durumu ortaya koyuyoruz.
Event’leri şu şekilde sınıflandırmamız mümkün:
Bunların yanında bir event’in bir başkasını tetiklemesi de mümkün.
Event’leri çıkarma aşamasında teknik detaylara girmemeye dikkat etmekte fayda var. Genelde programcıların zihinlerinde hemen sınıflar, tablolar uçuşmaya başlıyor ancak eğer Domain-Driven Design prensiplerine bağlı kalmak istiyorsak teknik çözümün çıktılarından uzak kalmak ve büyük resme model seviyesinde bakmak şu aşamada yararlı olacaktır. Zaten ES oturumu sonunda domain yapısı daha net görünüyor; modeller, bounded-context’ler ve aggregate’ler daha belirgin hale gelmiş oluyor.
İş kurallarını modellemek
Bir modelde sadece kişiler faaliyet göstermez, aynı zamanda sistemin de yaptığı şeyler vardır. Bunları da modelde göstermek istediğimizde açık mor renkli post-it kullanıyoruz. Bu post-it’lere Policy adı veriliyor.
Domain uzmanının ağzından “…. olduğunda, …. yapılacak” cümlesini duyduğumuzda modelleme alanına mor bir not yapıştırma zamanı gelmiş demektir. Cümlenin “… olduğunda” kısmı bir event, “… yapılacak” kısmı ise event gerçekleştiğinde sistemin gerçekleştireceği işlem olarak düşünülürse Policy’ler için event’lere verilecek reaksiyonlar olarak da bakabiliriz. Policy karmaşık bir akış barındırıyorsa, isteğe göre bu Policy’yi de detaylandırarak modellemeniz mümkün ancak detaylara girmeyi büyük resim ortaya çıktıktan sonra yapmanızı öneririm. Ayrıca birçok modelleme çalışmasında da göreceksiniz ki reaksiyonlar da sonrasında farklı event’lerin çalışmasına sebep olabiliyor:
Event’ler başka event’ler tarafından tetiklenebileceği gibi, kullanıcıların aksiyonları sonrasında da gerçekleşebilir.
Aktör etkileşimleri
Yukarıda da görebileceğiniz gibi kullanıcı tarafından gerçekleştirilen aksiyonları mavi post-it ile gösteriyoruz. Mavi post-it’ler için kullandığımız isim Command. Command’ler kullanıcılar tarafından üretilebildiği gibi harici (external) sistemler tarafından da üretilebilir. Eğer Command insan eli ile üretilmişse üzerine Cin Ali çizdiğimiz minik sarı bir post-it’i mavi notun hemen yanına iliştiriyoruz. Mavi notları kullanıcıların karar aldıkları anları belirtmek için de kullanabilirsiniz.
Modellemeye aktörleri de dahil ettiğimizde domain uzmanları için biraz daha somut bir görüntü ortaya çıkmaya başlıyor diyebiliriz. Zira artık event’leri kimlerin gerçekleştirdiği, olayların gerçekleşme akışı içinde aktörlerin sistemle nasıl etkileşime girdiğini de görmeye başlıyoruz.
Modelleme yaparken, Command ve Event notlarının üzerinde yazan cümlelerde genelde sadece gramer olarak farklılıklar ortaya çıktığına şahit olacaksınız. “Çağrıyı Sonlandır” ve “Çağrı Sonlandırıldı” örneğinde olduğu gibi. Yine de bunları yazmaktan çekinmeyin. Geri dönüp modelin üzerinden geçmeye başladığınızda tek bir Command sonrası birden çok farklı event’in devreye girdiğini ve modelin zenginleşmeye başladığını göreceksiniz.
Modeller ve UI
Modelleme sırasında sadece Command, Event ve aktörlerle çalışmıyoruz. Bir aktörün belli bir Command’i gerçekleştirmesi sırasında ihtiyaç olan modelleri ya da arayüzleri de modelleme alanında gösterebiliriz. Böylece ES sonunda DDD pratiklerine daha uygun bir çıktı elde etmiş oluyoruz.
Yukarıdaki örnekte bir aktörün gerçekleştirdiği Sipariş Ver komutu sırasında kullanılan modeli küçük yeşil bir post-it kullanarak gösterdik. Burada ihtiyaç olan veri doğrudan bir model ile eşleşmiyorsa, ya da bu iş halihazırda belli bir ekran/form üzerinden bir Command ile gerçekleştiriliyorsa yeşil post-it’i bu ekranın adını gösterecek şekilde de kullanabilirsiniz. Örn. Sipariş Formu.
Yukarıdaki örnekte bir de pembe post-it kullandım. Bu post-it harici bir sistemi gösteriyor. İçinde nasıl bir süreç yürüdüğü şu aşamada bizi ilgilendirmediği için Tedarikçi Sistemi notunu alarak post-it’i yapıştırıp geçiyoruz.
Sonuç
Gördüğünüz gibi sıkı sıkıya belli bir kural kümesine bağlı kalmadan gayet rahat ve eğlenceli bir şekilde domain modellemesi yapabileceğiniz bir araç Event Storming. Çalıştığım şirkette (Doğuş Teknoloji) birçok projede uygulamaya başladığımız ve iş süreçlerini çok hızlı bir şekilde öğrenmeyi sağlayan bir çalışma diyebilirim.
Belki daha ileride, Event Storming sonuçlarından nasıl Domain-Driven Design aşamasına geçtiğimizden, bounded-context’lerden mikroservislere giden yolda Event Storming’in nasıl bir faydası olduğundan da söz ederim, kim bilir :-)
Umarım işinize yaramıştır.
