Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Bu yazıda BPMN ile sadece tek bir süreci değil, birden fazla sürecin birbiriyle nasıl konuştuğunu öğreneceksin. Mesajlaşma, sinyal gönderme ve farklı katılımcıların (müşteri, kasiyer, barista gibi) aynı akış içinde nasıl modellenebileceğini net bir şekilde anlayacaksın. Yazının sonunda “end-to-end süreç” dediğimiz uçtan uca modelin mantığı kafanda oturmuş olacak.
Tek Bir Süreçle Başlamak: Kahve Siparişi Örneği
Şimdi şöyle bir düşün: Bir kafeye gidiyorsun, sipariş veriyorsun, ödeme yapıyorsun ve siparişinin hazırlanmasını bekliyorsun.
Bu aslında tek bir süreç gibi görünür ama içinde birden fazla aktör vardır. BPMN’de bu süreci modellediğinde genelde ilk olarak tek bir “pool” (katılımcı) ile başlarsın.
Pool (Havuz)
Bir süreci sahiplenen kişi ya da sistemi temsil eder.
Yani şöyle düşün:
Bir havuz, “bu sürecin sahibi kim?” sorusunun cevabıdır. Örneğin kasiyer.
Bu ilk modelde kasiyer siparişi alır, ödemeyi yapar, baristaya iletir ve müşteriye teslim eder. Ama burada kritik bir şey var: Bu süreç aslında tek başına değil.
Süreçler Arası İletişimi Nasıl Fark Edersin?
Sen de fark etmişsindir ki gerçek hayatta hiçbir süreç izole çalışmaz. BPMN’de bunu anlamanın en kolay yolu mesajlara bakmaktır.
Message Event (Mesaj Olayı)
Bir sürecin başka bir sürece veri göndermesi veya ondan veri almasıdır.
Bunu şöyle hayal edebilirsin:
WhatsApp’tan birine mesaj atıyorsun. Senin uygulaman başka bir uygulamayla konuşuyor.
Eğer modelde “mesaj gönder” veya “mesaj al” varsa, bu şu anlama gelir:
Bu sürecin dışında başka bir aktör daha var.
Bu sayede sistemdeki diğer katılımcıları keşfedersin:
- Müşteri
- Barista
- Mağaza yöneticisi
Yeni Katılımcılar Eklemek: Pool Mantığı
Bu noktada her aktör için ayrı bir pool oluşturursun.
Örneğin:
- Müşteri sipariş gönderir
- Kasiyer siparişi alır
- Barista kahveyi hazırlar
Başlangıçta bu pool’ları “collapsed” (içi boş) bırakabilirsin.
Collapsed Pool (Kapalı Havuz)
İç detaylarını göstermediğin ama varlığını bildiğin süreçtir.
Yani şöyle düşün:
Bir kara kutu. İçinde ne olduğunu bilmiyorsun ama dışarıyla nasıl konuştuğunu biliyorsun.
Bu yaklaşım hızlı modelleme için çok güçlüdür.
Mesaj Akışları: Süreçler Nasıl Konuşur?
Message Flow (Mesaj Akışı)
Farklı pool’lar arasındaki iletişimi gösterir.
Bunu şöyle hayal edebilirsin:
Farklı mikroservisler arasında API çağrıları.
Örneğin:
- Müşteri → Kasiyer (sipariş gönderir)
- Kasiyer → Barista (kahve talebi gönderir)
- Kasiyer → Müşteri (sipariş hazır bildirimi)
Burada önemli bir nokta:
Mesajlar her zaman farklı pool’lar arasında olur. Aynı pool içinde message flow olmaz.
Multi-Instance: Aynı İşin Birden Fazla Kez Yapılması
Barista tarafında ilginç bir durum var.
Bir siparişte 5 kahve olabilir. Bu durumda barista süreci aynı anda 5 kez çalışır.
Multi-Instance (Çoklu Çalıştırma)
Bir görevin aynı anda birden fazla kez çalıştırılmasıdır.
Yani şöyle düşün:
Aynı anda 5 ayrı kahve hazırlanıyor ama tek bir siparişe ait.
Bu durumda:
- Her kahve ayrı işlenir
- Ama süreç, hepsi bitmeden tamamlanmaz
Send Task vs Send Event: Hangisini Ne Zaman Kullanmalısın?
Burada küçük ama kritik bir ayrım var.
Send Event (Mesaj Gönderme Olayı)
Tek seferlik, basit mesaj gönderimi.
Send Task (Mesaj Gönderme Görevi)
Daha kompleks, birden fazla mesaj gönderebilen yapı.
Aslında bu çok basit:
- Tek mesaj → Event kullan
- Birden fazla veya tekrar eden işlem → Task kullan
Örneğin multi-instance durumunda event yeterli olmaz, task kullanman gerekir.
Süreci Genişletmek: Müşteri Davranışını Modellemek
Şimdi şöyle bir düşün: Sipariş verdin ve bekliyorsun.
Ama bu sırada:
- Telefonuna bakabilirsin
- Sıkılabilirsin
- Gidip tekrar sorabilirsin
İşte burada devreye girer:
Boundary Event (Sınır Olayı)
Bir görev devam ederken ortaya çıkan alternatif durumları yakalar.
Bunu şöyle hayal edebilirsin:
Bir işi yapıyorsun ama aynı anda başka bir şey seni bölüyor.
Örneğin:
- “Siparişi bekle” görevi var
- 1 dakika geçerse → “telefonu kontrol et”
Bu sayede süreç daha gerçekçi olur.
Asenkron İletişim: Beklemek ve Tekrar Hatırlatmak
Gerçek hayatta iletişim her zaman anlık değildir.
Asynchronous Communication (Asenkron İletişim)
Mesaj gönderilir ama cevap hemen gelmez.
Yani şöyle düşün:
Birine mesaj attın ama “görüldü” bile gelmedi.
Kahve örneğinde:
- Kasiyer müşteriyi çağırır
- Müşteri gelmezse 5 dakika sonra tekrar çağırır
Bu, BPMN’de zamanlayıcı (timer) ile modellenir.
Signal Event: Herkese Aynı Anda Mesaj
Burada iş biraz daha ilginçleşiyor.
Signal Event (Sinyal Olayı)
Belirli bir kişiye değil, herkese yayınlanan mesajdır.
Bunu şöyle hayal edebilirsin:
Yangın alarmı. Kim varsa duyar.
Örneğin:
- Kahve çekirdeği bitti
- Sistem “dükkanı kapat” sinyali gönderir
Bu sinyal:
- Kasiyeri etkiler
- Baristayı etkiler
- Müşteriyi etkiler
Herkes sürecini sonlandırır.
Error ve Escalation: Sorunları Yönetmek
Bazen işler planlandığı gibi gitmez.
Error Event (Hata Olayı)
Sürecin devam edemeyeceği kritik hatalar.
Escalation Event (Yükseltme Olayı)
Sorunun bir üst seviyeye iletilmesi.
Yani şöyle düşün:
- Error → “Bu iş bitti, devam edemem”
- Escalation → “Ben çözemiyorum, bir üstüne haber ver”
Örneğin:
- Ürün yok → müşteri para iadesi alır (escalation)
- Kahve yok → tüm sistem kapanır (error + signal)
End-to-End Süreç: Büyük Resmi Görmek
Artık tek bir süreç değil, birden fazla sürecin birleşimini görüyorsun:
- Müşteri süreci
- Kasiyer süreci
- Barista süreci
- Yönetici süreci
Hepsi birlikte çalışır.
End-to-End Process (Uçtan Uca Süreç)
Bir işin baştan sona tüm aktörleriyle modellenmesidir.
Bunu şöyle hayal edebilirsin:
Bir e-ticaret siparişi:
- Kullanıcı sipariş verir
- Ödeme sistemi çalışır
- Kargo devreye girer
Hepsi ayrı ama aynı hikâyenin parçası.
Özet
Aslında bu modelin anlattığı şey oldukça net: Gerçek hayattaki süreçler hiçbir zaman tek başına çalışmaz. BPMN’de bunu doğru modellemek için önce mesajları takip ederek diğer aktörleri keşfedersin, ardından her biri için ayrı havuzlar oluşturursun. Bu havuzlar arasındaki iletişimi message flow ile bağlarsın. Daha karmaşık durumlarda multi-instance, boundary event ve timer gibi yapılarla süreci gerçeğe yaklaştırırsın. Kritik durumlar için error, escalation ve signal event kullanarak sistemin nasıl tepki verdiğini tanımlarsın. Sonuçta ortaya çıkan şey, sadece bir akış değil, tüm sistemin birlikte nasıl çalıştığını gösteren uçtan uca bir model olur.
Bu yazı BPMN Message Events and Message Flows Explained videosundan ilham alınarak yazılmıştır.
