Bir B2B SaaS ürününde aynı platformdan satılan hizmetler farklı operasyonlar gerektiriyordu. Bazısında belge toplanıyor, bazısında uzman incelemesi yapılıyor, bazısında da bir başvurunun aşamaları takip ediliyordu. Operasyon ekibinin her yeni hizmet için geliştirme beklemeden bu akışları yönetebilmesi gerekiyordu.
Laravel üzerinde, önceden tanımlanmış adım türlerinden hizmet kurulabilen bir yapı geliştirdim. İşin kritik kararı hangi adımların bulunacağı kadar, hizmet şablonuyla müşterinin devam eden işleminin birbirinden ayrılmasıydı.
Hizmet şablonu ile müşteri kaydını ayırmak
Operasyon ekibi yönetim panelinde adımları seçip sıralıyor. Bir müşteri hizmeti satın aldığında bu adımların kendisine ait örnekleri oluşturuluyor. Belgeler, ilerleme ve uzman notları bu örneklerde tutuluyor; ortak şablonun içine yazılmıyor.
Böylece bir müşterinin dosyasında yapılan işlem başka müşterileri etkilemiyor. Aynı adım türünün arayüzü yeniden kullanılabiliyor, ancak müşterinin gördüğü durum kendi kaydından geliyor. Şablonu düzenlemek ile devam eden işi yönetmek farklı sorumluluklar olarak kalıyor.
Adımlar arasındaki bağı olaylarla kurmak
Alan kuralları gelişmeye devam ettiği için uygulamayı bağımsız servislere bölmek yerine modüler bir monolit içinde tuttum. Bir adım diğerini doğrudan çalıştırmıyor. Tamamlandığında olay yayımlıyor; dinleyiciler görünürlük ve ilerleme durumunu yeniden hesaplıyor.
Bu ayrım e-fatura entegrasyonunda işe yaradı. Hizmet içinde alınan ödemeleri faturalamaya bağlamak için ilgili ödeme olayına bir dinleyici eklenebildi. Belge toplama veya uzman incelemesi bileşenlerine faturalama bilgisi eklemek gerekmedi.
Revizeyi neden ayrı bir adım olmaktan çıkardım?
İlk tasarımda reddedilen belge için ayrıca revize adımı açılıyordu. Bu seçim, genel akış motoruna yalnız bu tür için görünürlük ve geçiş istisnaları ekledi. Oysa revize müşterinin geçtiği bağımsız bir aşama değil, mevcut belgenin yeniden işlem görmesiydi.
Revizeyi belgenin durumuna taşıdım. İnceleme yeniden yükleme gerektiriyorsa belge adımı açılıyor, sonraki adımların görünürlüğü yeniden hesaplanıyor. Bu sırada daha önce girilmiş veriler silinmiyor. Müşteri aynı işin devamını görüyor; motor ikinci bir akış türünü yönetmiyor.
Yeni bir adım eklemeden önce baktığım sınır
Bu yapı, her operasyon kuralını yeni bir adım türüne dönüştürmek için kurulmadı. Yeni ihtiyaçta önce müşterinin bağımsız bir aşamadan mı geçtiğine, yoksa mevcut bir kaydın durumunun mu değiştiğine bakıyorum. İkinci durumda çözüm çoğunlukla yeni bileşen değil, mevcut modelin doğru yerde güncellenmesi oluyor.