Saklı yordamlar vs görsel iş akışları: mantık nerede olmalı

Bu kararın gerçekten ne anlama geldiği

İş mantığı, neyin izinli olduğunu, bir sonraki adımda ne olacağını ve gerçek insanların sistemi kullandığında sistemin ne yapacağını belirleyen kurallar kümesidir. Veri kendisi değildir. Davranıştır: kimin ne yapabileceği, hangi koşullarda ve hangi yan etkilerle.

Dolayısıyla saklı yordamlar vs görsel iş akışları tartışması aslında bu kuralların nerede tutulması gerektiği ile ilgilidir — böylece değiştirilmeleri kolay, bozulmaları zor ve süreci sahiplenen kişiler için açık olur.

Çoğu ekip mantık için üç olası “ev” ile sonuçlanır:

• Veritabanında (saklı yordamlar, tetikleyiciler, kısıtlar): kurallar veriye yakın çalışır. Bu hızlı ve tutarlı olabilir, ama veritabanı uzmanı olmayanlar için değiştirmesi daha zor olabilir.
• Görsel iş akışlarında (sürükle-bırak proses oluşturucular): kurallar adımlar ve kararlar olarak ifade edilir. Süreç değiştikçe okunması, gözden geçirilmesi ve ayarlanması genellikle daha kolaydır.
• Özelleştirilmiş kodda (servisler, uygulamalar, scriptler): kurallar bir programlama dilinde yazılır. Bu maksimum esneklik sağlar, ama değişiklikler genellikle daha fazla mühendislik disiplini ve test gerektirir.

Seçim günlük hız ve uzun vadeli bakım üzerinde etkilidir. Mantığı yanlış yere koyarsanız teslimat yavaşlar (her değişiklik veritabanını bilen tek kişiye bağımlıdır), hata sayısı artar (kurallar birden çok yerde çoğaltılır) ve hata ayıklama acı verici olur (kimse bir kaydın neden reddedildiğini bilmez).

Çoğu sistem birkaç tür iş mantığı içerir. Yaygın örnekler doğrulama (zorunlu alanlar, izin verilen aralıklar), onaylar, fiyatlandırma ve indirimler, bildirimler ve erişim kurallarıdır.

Pratik bir şekilde düşünmek gerekirse: veritabanı veri bütünlüğünü korumada iyidir, görsel iş akışları iş süreçlerini ifade etmede iyidir ve özelleştirilmiş kod kuralı temiz bir şekilde modellemek için çok benzersiz veya karmaşık olduğunda iyidir. AppMaster gibi platformlar orta noktada güçlü şekilde durur: veriyi modelleyebilir, sonra süreci okunabilir görsel mantıkla uygulayabilirsiniz; böylece kurallar birçok uygulamaya dağılmaz.

Kriterler: neyi optimize ediyorsunuz

Bu gerçekten bir zevk meselesi değil. Korumaya çalıştığınız şeye bağlı: veriyi, sistemi değiştiren insanları ve değişim hızını.

Önemli sonuçlar

Projeniz için en önemli sonuçları isimlendirin. Çoğu ekip şu karışımı dengeler:

• Doğruluk: kurallar her zaman aynı şekilde çalışmalı, hatta yük altındayken bile.
• Açıklık: yeni birisi tahmin yürütmeden ne olduğunu anlamalı.
• Hız: mantık gerektiğinde hızlı ve veriye yakın çalışmalıdır.
• Denetlenebilirlik: kimin neyi değiştirdiğini ve ne zaman çalıştığını ispatlamanız gerekebilir.
• Değişim hızı: gereksinimlerin haftalık değil yıllık olarak değişmesini beklemiyorsunuz.

Bu beşinin hepsini nadiren maksimize edersiniz. Mantığı veritabanına yaklaştırmak doğruluk ve hızı artırabilir, ama SQL ile yaşamayan insanlar için açıklığı azaltabilir.

Mantığı kim değiştirecek (ve ne sıklıkla)

Günlük değişikliklere kimin sahip olacağını dürüstçe değerlendirin. Operasyonların haftada bir ayarlaması gereken bir kural saklı yordamın deploy edilmesini gerektirmemeli. Aynı zamanda parayı etkileyen bir kural inceleme olmadan düzenlenmemeli.

Değişim sürtünmesi açısından düşünün. Gereksinimler sık değişiyorsa, güncellemelerin güvenli, görünür ve hızlı dağıtılabileceği bir yer istersiniz. Görsel iş akışı araçları (örneğin AppMaster'ın Business Process Editor'ü) iş sahipleri ve mühendislerin düşük seviyeli kod düzenlemeden mantık üzerinde iş birliği yapması gerektiğinde iyi çalışabilir. Değişiklikler nadir ve kural kritikse, daha yüksek sürtünme kabul edilebilir.

Sahipliği sınama için hızlı sorular:

• Saat 2'de başladığında kim çağrılıyor?\n- Bir kuralı ne kadar çabuk yamalamanız gerekiyor?\n- Değişikliklerin onayları veya kağıt izi gerekli mi?\n- Aynı kurala birden çok uygulama bağlı mı olacak?\n- Mantık ağırlıklı olarak veri şekillendirme mi yoksa iş kararları mı?

Sınırları erken düşünün. Bazı sektörler sıkı erişim kontrolü, görev ayrımı veya detaylı günlükler gerektirir. Ayrıca veri erişim sınırlarını değerlendirin: yalnızca belirli servislerin bazı alanları görmesi gerekiyorsa, bu mantığın nerede güvenle çalışabileceğini etkiler.

Mantığın saklı yordamlarda olması gerektiği durumlar

Saklı yordamlar, veritabanı içinde çalışan mantık parçalardır. PostgreSQL'de genellikle SQL (ve bazen PL/pgSQL gibi veritabanı dilleri) ile yazılırlar. Uygulamanız satırları çekip, döngüyle dolaşıp değişiklikleri geri itmek yerine, veritabanı verinin olduğu yerde işi yapar.

Basit bir kural: işin ana görevi veriyi korumak ve toplu veri işlemi yapmaksa mantığı veritabanına koyun; insanları veya sistemleri koordine etmekse koymayın.

Saklı yordamların parladığı yerler

Saklı yordamlar, hangi uygulama ya da entegrasyon veritabanına dokunursa dokunsun hep doğru olması gereken kurallar için uygundur. Kötü veriyi engelleyen koruyucu bariyerler düşünün.

Ayrıca binlerce satırı güvenli ve hızlı şekilde güncelleyebilen set-temelli güncellemelerde de mükemmeldirler. Toplamları hesaplama veya sabit bir indirim formülünü uygulama gibi yalnızca veriyle ilgili basit hesaplamalar da burada olabilir; bu round-tripleri azaltır ve sonuçları tutarlı tutar.

Örnek: Bir sipariş paid olarak işaretlendiğinde, bir prosedür sipariş durumunu atomik olarak güncelleyebilir, stoktan düşebilir ve bir denetim kaydı yazabilir. Herhangi bir adım başarısız olursa tüm değişiklik geri alınır.

Saklı yordamlar riskli hale geldiğinde

Saklı yordamlar uygulama kodundan daha zor testlenip sürümlenebilir; özellikle ekibiniz veritabanı değişikliklerini gerçek sürümler gibi ele almıyorsa. Mantık uygulamadan “gizlenmiş” hale gelebilir ve bu daha sonra keşfettiğiniz bağımlılıklara yol açar.

Hata ayıklamak da zordur. Hatalar daha az bağlam içeren veritabanı mesajları olarak ortaya çıkabilir. Yeni ekip üyeleri uygulama ve veritabanı arasında bölünmüş kurallar yüzünden zorlanabilir. Eğer görsel araç çoğu mantık için kullanılıyorsa, saklı yordamları veriye yakın çalışması gereken küçük, stabil çekirdekle sınırlayın. Diğer her şeyi okunması, izlenmesi ve değiştirilmesi daha kolay bir yerde tutun.

Mantığın görsel iş akışlarında en iyi uyduğu durumlar

Görsel iş akışları, bir kontrol listesi gibi okunabilen adım adım süreç mantıklarıdır: bir şey olduğunda bu eylemleri sırayla çalıştırın, net karar noktalarıyla. Ağır hesaplamadan çok işin insanlara, sistemlere ve zamana nasıl aktığını gösterirler.

Paylaşılan anlayışın önemli olduğu durumlarda parıldarlar. Ürün, operasyon, destek ve mühendisliğin hepsinin bir sürecin nasıl çalıştığı konusunda anlaşması gerekiyorsa, görsel bir iş akışı kuralları görünür kılar. Bu görünürlük genellikle “sistem bozuk” ile “süreç geçen hafta değişti” arasındaki farktır.

Görsel iş akışları onaylar ve incelemeler, yönlendirme, bildirim ve hatırlatmalar, zamanlanmış adımlar (2 gün bekle, sonra yükselt) ve entegrasyonlar (Stripe çağır, mesaj gönder, CRM güncelle) için genellikle iyi bir seçimdir.

Örnek: Bir müşteri iade talep ediyor. İş akışı sipariş yaşını kontrol eder, eğer eşik üzerinde ise yöneticiyi çağırır, onaylandığında finansı bilgilendirir ve müşteriye güncelleme gönderir. Her adım açıkça işaretlenebilir ve paydaşların onayı ve yeni ekip üyelerinin “neden”i anlaması kolaylaşır.

AppMaster'ın Business Process Editor'ü gibi araçlar bu tür mantık için tasarlanmıştır: yol, koşullar ve yan etkileri (mesajlar, API çağrıları, durum değişiklikleri) veritabanı betiklerine bakmadan görülebilir.

İş akışlarının makarna haline gelmesini önlemek için onları küçük ve okunabilir tutun. Her iş akışına tek bir sonuç verin, adımlara ve dallanmalara açıklayıcı isimler koyun, derinçe iç içe geçmiş kararları sınırlayın ve "neden böyle oldu?" sorusuna cevap verebilmek için kilit seçimleri kaydedin.

Bir iş akışı karmaşık veri hesaplamaları yapmaya veya birçok tabloya dokunmaya başladığında, mantığın bir kısmını başka bir yere taşımak için sinyal alırsınız. Görsel iş akışları orkestra şefi gibi çalıştığında en iyisidir, tüm orkestrayı oluşturduğunda değil.

Özelleştirilmiş kod doğru araç olduğunda

Özelleştirilmiş kod, yazdığınız ve yazılım olarak bakımını yaptığınız mantıktır: fonksiyonlar, servisler veya uygulamanızın parçası olarak çalışan küçük kütüphaneler. En esnek seçenektir ve bu yüzden amaçlı kullanılmalıdır, rastgele değil.

Kod, mantığın veritabanı prosedüründe veya sürükle-bırak iş akışında güvenli bir şekilde ifade edilmesinin zor olduğu durumlarda yerini hak eder. Problemi araca uydurmaya çalışıyorsanız, kod genellikle daha net ve doğru tutulması daha kolaydır.

Koda başvurmanız gerektiğini gösteren güçlü işaretler:

• Problem algoritmik (fiyatlandırma kuralları, rota planlama, puanlama, eşleştirme, dolandırıcılık kontrolü) ve çok sayıda uç vaka içeriyor.
• Alışılmadık bir entegrasyon gerekiyor (garip kimlik doğrulaması, karmaşık retry, sıkı idempotency kuralları).
• Performans duyarlı (yüksek hacimli işleme, ağır hesaplamalar, dikkatli cache gereksinimi) ve sıkı kontrol istiyorsunuz.
• Aynı mantığı farklı yerlerde (web, mobil, batch işler) paylaşmanız gerekiyor, kopyalamadan.
• Hataların çok maliyetli olması sebebiyle mantık etrafında güçlü otomatik testlere ihtiyacınız var.

Kod ayrıca sahipliği netleştirir. Bir ekip değişiklikleri incelemekten, testleri yeşil tutmaktan ve davranışı dokümante etmekten sorumlu olabilir. Bu, “üç iş akışında yaşıyor ve kimse hangisinin önce çalıştığını bilmiyor” durumundan daha iyidir.

Örnek: sipariş geçmişi, dolandırıcılık sinyalleri, gönderi durumu ve zaman pencerelerini dikkate alan bir iade karar motoru. Onay adımlarını görsel iş akışında tutabilirsiniz, ama karar genellikle birim testleri ve versiyon kontrolü ile kod olarak yazılmalıdır.

Maliyeti gerçektir. Özelleştirilmiş kod mühendislik zamanı, incelemeler ve sürekli bakım gerektirir. Değişiklikler bir iş akışını düzenlemekten daha uzun sürebilir ve bir sürüm süreci gerektirir. AppMaster, görsel mantık ve modüllerle ortak kısımları karşılayarak ne kadar koda ihtiyaç duyduğunuzu azaltabilir; aynı zamanda ekiplerin gerektiğinde kaynak kodu dışa aktarmasına ve genişletmesine izin verir.

Yeniden kullanabileceğiniz adım adım çerçeve

Ekipler en faydalı kısmı sık sık atlar: kuralı açıkça yazmak, sonra kuralın davranışına uygun bir ev seçmek.

Yeni bir mantık ortaya çıktığında bu çerçeveyi kullanın:

• Kuralı bir cümle olarak yazın, sonra etiketleyin. Veriyle ilgiliyse (kısıtlar, benzersizlik, toplamların eşleşmesi) veri kuralıdır. Adımlar ve el değişimleriyle ilgiliyse (onaylar, beklemeler, bildirimler) süreç kuralıdır. Ağır matematik veya karmaşık dönüşümler içeriyorsa hesaplama kuralıdır.
• Kim düzenliyor ve ne sıklıkla? Teknik olmayan kişilerin haftalık değiştirmesi gerekiyorsa SQL veya kod sürümü gerektirmeyin. Nadiren değişip her zaman zorunluysa veritabanı daha güçlü bir adaydır.
• Hata etkisini ve ihtiyaç duyduğunuz denetim izini kontrol edin. Hata para kaybına, uyum sorunlarına veya zor düzeltilen verilere yol açıyorsa, net loglama ve sıkı kontrol sunan bir yer tercih edin.
• Konumu seçin ve sınırı tanımlayın. Girdi, çıktı ve hatalar hakkında açık olun. Örnek: “Bir order_id verildiğinde, allowed_refund_amount döndür veya açık bir reason code ver.” Bu sınır mantığın her yere sızmasını engeller.
• Bir katmanı ince tutun. Hangi katmanın çoğunlukla “aptal” kalacağını karar verin ki kurallar çoğaltılmasın. Yaygın seçimler: veritabanını ince tut (sadece veri bütünlüğü), iş akışlarını ince tut (sadece orkestrasyon), veya kodu ince tut (sadece glue).

Kural parmak kuralı: veri kurallarını veriye en yakın koyun, süreç kurallarını iş akış aracına koyun ve hesaplama kurallarını test edip sürümlendirmesi en kolay yerde tutun.

AppMaster kullanıyorsanız veritabanını bariyerler (tablolar, ilişkiler, temel kısıtlar) olarak ele alabilir, Business Process Editor'u “kim neyi sonra yapar” kısmı için kullanabilir ve gerçekten ihtiyaç duyulan vakalar için özelleştirilmiş kodu saklayabilirsiniz.

Karmakarışık sistemlere yol açan yaygın hatalar

Karmaşık sistemler nadiren tek bir kötü seçim yüzünden oluşur. Mantığın etrafa dağılması, gizlenmesi veya kopyalanmasıyla olur; sonuçta hiç kimse sistemin aslında ne yaptığını bilmez.

Çoğaltma klasik problemdir: aynı kural iki yerde var ama zamanla farklılaşıyor. Örnek: veritabanı $500 üzerindeki iadeleri onay olmadan reddediyor ama bir iş akışı farklı bir limiti kontrol ediyor. İkisi “çalışır” gibi görünür ta ki gerçek bir uç vaka çıkana kadar; sonra destek için gizemli bir hata doğar.

Gizli kurallar da ikinci sıradadır. Tetikleyiciler, saklı yordamlar ve veritabanındaki hızlı düzeltmeler UI veya iş akışlarını yapan kişiler için görünmez olabilir. Kural iş akışı veya API'nin yanında dokümante değilse, değişiklikler tahmin yürütme olur ve test etme deneme-yanılma haline gelir.

Aşırı dolu iş akışları farklı bir tür karmaşa yaratır. Onlarca dallanması olan uzun sürükle-bırak zinciri kırılgan bir nesne haline gelir ve kimse ona dokunmak istemez. AppMaster gibi araçlarda blok eklemek kolaydır, ama hız bugün için kafa karışıklığına dönüşebilir eğer iş akışının sınırları net değilse.

İki karşıt “çok fazla” hatası uzun vadede acı verir:

• Veritabanında çok fazla şey: her politika değişikliği bir migration projesi olur ve küçük ürün değişiklikleri veritabanı sürümlerini bekler.
• Uygulama kodunda çok fazla şey: temel veri kuralları (zorunlu alanlar, izin verilen durumlar, benzersiz kısıtlar) unutulur ve importlar, admin araçları veya gelecekteki entegrasyonlar kötü veri sokar.

Basit bir alışkanlık çoğunun önünü alır: her kuralı birincil bir evde tutun ve nerede yaşadığını ve nedenini yazın. “Bu nerede uygulanıyor?” sorusuna 10 saniyede cevap veremiyorsanız, zaten karmaşa vergisini ödüyorsunuz.

Hızlı kontroller: 2 dakikada karar verin

Bir kuralı nerede tutmanın en kolay yolu: onu doğru, görünür ve değiştirilebilir tutmanın en kolay yeri neresi?

Tek bir soruyla başlayın: Bu kural veri doğruluğu ile mi ilgili, hiç atlanmaması mı gerekiyor? Eğer evet ise veritabanına yaklaştırın. Eğer adımlar, onaylar veya bildirimler ile ilgiliyse iş akışı katmanına yakın tutun.

Hızlı kontrol listesi:

• Veri doğruluğunu sağlıyor mu (negatif stokları engellemek, aynı anda birden fazla "active" kayıt oluşturmayı engellemek)? Veritabanı tarafına eğilin.
• Birçok tabloya dokunup set-temelli güncellemeler mi yapıyor (çok sayıda satır)? Veritabanı.
• Kim onayladı, ne zaman gibi okunabilir denetim izi mi lazım? İş akışı.
• Teknik olmayanların haftalık veya aylık değiştirmesi mi gerekecek? İş akışı.
• Harici servisler çağırıyor mu (ödeme, mesajlaşma, AI)? Uygulama veya iş akışı, veritabanı değil.

Şimdi hatayı düşünün. Başarısız olabilecek bir kural insan tarafından kurtarılabilir şekilde başarısız olmalı.

Güvenli yeniden denemeler ve açık hata mesajları gerekiyorsa, durumu izleyip istisnaları adım adım ele alabileceğiniz bir orkestrasyon katmanını tercih edin. Görsel iş akışı araçları bunu kolaylaştırır çünkü her adım açıktır ve loglanabilir.

Pratik bir tie-breaker:

• Sistem daha sonra yeni bir uygulama yazıldığında bile doğru kalmalıysa veritabanında zorlayın.
• Sürecin operasyon ekipleri tarafından okunup gözden geçirilmesi amaçlanıyorsa görsel iş akışında tutun.
• Karmaşık entegrasyonlar, ağır hesaplamalar veya özel kütüphaneler gerekiyorsa özelleştirilmiş kod kullanın.

Örnek: “İade tutarı orijinal ödemeyi aşamaz” doğruluk ilkesidir, bu yüzden veriye yakın uygulanmalı. “$500 üzerindeki iadeler yönetici onayı gerektirir ve sonra Telegram ile bilgilendirme gönder” ise iş akışı tarafıdır. AppMaster'da bu onay zinciri Business Process Editor'de doğal olarak oturur, sıkı kısıtlamalar ise veri modelinde kalır.

Örnek senaryo: onaylı iadeler

Sık karşılaşılan gerçek dünya vakalarından biri, belirli bir tutarın üzerindeki iadelerin yönetici onayı, bildirimler ve temiz bir denetim izi gerektirmesidir.

Tek bir gerçek kaynağı tanımlayarak başlayın: tutarlar ve net bir durum alanı (örnek: requested, needs_approval, approved, rejected, processing, paid, failed) içeren bir Refund kaydı. Sisteminizin her parçası aynı alanları okumalı ve yazmalı; paralel durumlar tutmak yerine herkes aynı kaynağa bakmalı.

Veritabanında ne olmalı

Parayı ve veri tutarlılığını koruyan kuralları veriye en yakın tutun.

Kısıtlar (ve bazen bir saklı yordam) kullanarak, yakalanmış ödeme miktarından fazla iade yapılamayacağını, zaten tamamen iade edilmiş bir siparişe iade yapılamayacağını, aynı sipariş için iki aktif iade talebi oluşturulamacağını veya onaylandıktan sonra ana tutarların değiştirilemeyeceğini sağlayın.

Ayrıca atomik güncellemeleri burada tutun: bir iade talebi oluşturulduğunda, Refund satırını yazın ve Order toplamlarını tek bir işlemde güncelleyin. Yazma işlemlerinden biri başarısız olursa, hiçbir şey kısmen güncellenmemeli.

Görsel iş akışında ne uygun

Onay adımları veri koruması değil süreçtir. Bir görsel iş akışı isteği doğru yöneticiye yönlendirmek, karar beklemek, durumu güncellemek, hatırlatmalar göndermek ve isteği talep edene bildirmek için uygundur.

Basit bir akış şöyle olabilir: istek oluştur -\u003e eğer tutar limit üzerindeyse durum needs_approval olarak ayarlanır -\u003e yöneticiye bildirim gönderilir -\u003e onaylanırsa approved olarak ayarlanır -\u003e talep eden bilgilendirilir -\u003e 24 saat içinde cevap yoksa hatırlatma gönderilir.

AppMaster gibi bir araçta bu, durum değişikliklerine tepki veren ve e-posta, SMS veya Telegram mesajlarını tetikleyen bir Business Process olarak rahatça eşlenir.

Özelleştirilmiş kodda ne olmalı

Ödeme sağlayıcıları, kurallara tam uymayan uç vakalar içerebilir. Sağlayıcıya özgü mantığı özelleştirilmiş koda bırakın: ücretli kısmi iadeler veya çoklu capture durumları, webhook mutabakatı (sağlayıcı "paid" diyor ama uygulamanız "processing" diyor) ve sağlayıcı zaman aşımına uğradığında idempotency ve retry işlemlerinin yönetimi gibi.

Anahtar nokta: özelleştirilmiş kod kendi durumlarını icat etmemelidir. Refund kaydını okur, sağlayıcı aksiyonunu yapar ve sonra bir sonraki durumu ve onaylanmış tutarları yazar; böylece veritabanı herkesin güvendiği defter olmaya devam eder.

Bir sonraki adımlar: kararı kalıcı kılmak

İyi bir karar, altı ay sonra da geçerli kalırsa yararlıdır. Amaç, "mantık nerede yaşar?" seçimini görünmesi kolay, test edilmesi kolay ve kazara atlanması zor hale getirmektir.

Basit bir mantık haritası oluşturun: kilit kurallarınızın kısa listesi ve her biri için seçtiğiniz ev. Kısa tutun ve bir kural değiştiğinde güncelleyin. Kural adı, nerede yaşadığı (veritabanı, iş akışı, özelleştirilmiş kod), neden (bir cümle), neyi okuduğu ve yazdığı ve kimlerin değişiklikleri onayladığı bilgilerini ekleyin.

Sınırları değiştirilemez kurallar olarak yazın ki gelecekte özellik ekleyenler sistemi korusun. Yararlı bir format: “Veritabanı X'i garanti eder” ve “İş akışları Y'yi uygular.” Örnek: veritabanı bir Refund kaydının bir Order olmadan var olamayacağını garanti eder; iş akışı ise $500 üzerindeki iadelerin yönetici onayı gerektirdiğini uygular.

Herhangi bir değişiklik yapmadan önce test planı hazırlayın. Büyük bir plan gerekmez, sadece kural değiştiğinde her seferinde çalıştıracağınız birkaç vaka yeterlidir:

• Mutlu yol (beklenen giriş, beklenen sonuç)
• Hata yolu (eksik veri, geçersiz durum, çift istek)
• Eşzamanlılık (aynı anda iki kişinin aynı işlemi tetiklemesi)
• Güvenlik (bir kullanıcının adımları atlamaya veya doğrudan endpoint'i çağırmaya çalışması)

Ayrıca sahipliği ve inceleme kurallarını belirleyin. Kim saklı yordamları düzenleyebilir, kim iş akışlarını düzenleyebilir ve neyin peer review gerektirdiğini kararlaştırın. Buralar sistemin ya sağlıklı kalmasını ya da “neden böyle çalıştığını kimse bilmiyor” haline dönmesini ayırır.

Eğer sürükle-bırak iş akışları istiyor fakat gerçek backend yapısından vazgeçmek istemiyorsanız, AppMaster (appmaster.io) gibi bir platform pratik bir orta yol olabilir: verinizi modelleyin, Business Process Editor ile süreci ifade edin ve gereksinimler değiştikçe yeniden üretip dağıtın.

Bir yüksek etkili kural seçin, haritasını çıkarın, sınırları ekleyin ve üç test vakası yazın. Bu tek alışkanlık çoğu mantık yayılmasını engeller.