Bir Kural Motorunu ne zaman KULLANMAMALISINIZ? [kapalı]

Bir Kural Motoru kullanmanın avantajlarının ve bunları kullanmak için bazı nedenlerin oldukça iyi bir listesine sahibim, ihtiyacım olan şey, bir Kural Motoru KULLANMAMANIZ için nedenlerin bir listesi

Şimdiye kadar sahip olduğum en iyi şey şu:

Kural motorları, gerçekten iş akışını veya süreç yürütmelerini idare etmek için tasarlanmamıştır ve iş akışı motorları veya süreç yönetimi araçları kuralları uygulamak için tasarlanmamıştır.

Bunları kullanmamanız için başka büyük nedenler var mı?

İnsanların çok büyük kural kümeleri (örneğin, tek bir kural kümesindeki binlerce kural sırasına göre) kullandığını gördüğümde çok gergin oluyorum. Bu genellikle kural motoru, kuralları KURU tutmanın onları gerektiren birçok uygulama için erişilebilir hale getireceği umuduyla işletmenin merkezinde oturan bir tek kişi olduğunda gerçekleşir . Bu kadar kurala sahip bir Rete kuralları motorunun iyi anlaşıldığını söylemesi için kimseye meydan okuyorum. Çatışmaların olmadığından emin olmak için kontrol edebilecek herhangi bir araçtan haberdar değilim.

Bence bölümleme kuralları, onları küçük tutmak için daha iyi bir seçenek. Yönler, birçok nesne arasında ortak bir kural kümesini paylaşmanın bir yolu olabilir.

Mümkün olan her yerde daha basit, daha fazla veriye dayalı bir yaklaşımı tercih ederim.

Bir Kural Motoru kullanmanın kötü bir fikir olduğu kişisel deneyimlerden 2 örnek vereceğim, belki bu yardımcı olabilir: -

1. Geçmiş bir projede, kural dosyalarının (Drools kullandığı proje) döngüler, işlevler vb. Dahil olmak üzere çok sayıda java kodu içerdiğini fark ettim. Bunlar esasen kural dosyası olarak maskelenen java dosyalarıydı. Mimara tasarımın gerekçesini sorduğumda bana "Kuralların hiçbir zaman işletme kullanıcıları tarafından sürdürülmesi amaçlanmadı" söylendi.

Ders : Bunlara bir nedenle "İş Kuralları" denir, İşletme kullanıcıları tarafından kolayca idame ettirilebilecek / anlaşılabilecek bir sistem tasarlayamadığınızda kuralları kullanmayın.

2. Başka bir durum; Proje kuralları kullandı çünkü gereksinimler yetersiz tanımlandı / anlaşıldı ve sık sık değiştirildi. Geliştirme ekibinin çözümü, sık kod dağıtımlarından kaçınmak için kuralları kapsamlı bir şekilde kullanmaktı.

Ders : Gereksinimler, ilk sürüm değişiklikleri sırasında çok değişme eğilimindedir ve kuralların kullanımını garanti etmez. İşiniz sık sık değiştiğinde kuralları kullanın (gereksinimler değil) Örneğin: - Vergilendirme yasaları değiştikçe ve kuralların kullanımı her yıl vergilerinizi değiştirecek bir yazılım mükemmel bir fikirdir. Bir web uygulamasının 1.0 sürümü, kullanıcılar yeni gereksinimleri belirledikçe sık sık değişecek, ancak zamanla sabitlenecektir. Kod dağıtımına alternatif olarak kuralları kullanmayın.

Bir programcı olarak hayatınızı çok daha kolay hale getirmenize yardımcı olabileceğinden, İş Kuralları Motorlarının büyük bir hayranıyım. Bir Veri Ambarı projesi üzerinde çalışırken yaşadığım ilk deneyimlerden biri, tüm sayfalara yayılan karmaşık CASE yapılarını içeren Depolanan Prosedürleri bulmaktı. Bu kadar uzun CASE yapılarında uygulanan mantığı anlamak ve kodun 1. sayfasındaki bir kural ile 5. sayfadaki bir kural arasında örtüşme olup olmadığını belirlemek çok zor olduğundan, hata ayıklamak bir kabustu. Genel olarak, Kodda gömülü olan bu tür 300'den fazla kural.

3000'den fazla kuralı işlemeyi içeren Accounting Destination adlı bir şey için yeni bir geliştirme gereksinimi aldığımızda, bir şeyin değişmesi gerektiğini biliyordum. O zamanlar bir prototip üzerinde çalışıyordum ve bu prototip daha sonra şu anda bir Özel İş Kuralı motorunun ebeveyni olacak ve tüm SQL standart operatörlerini idare edebilecek. Başlangıçta bir yazma aracı olarak Excel kullanıyorduk ve daha sonra, İş Kullanıcılarının kod yazmaya gerek kalmadan kendi iş kurallarını tanımlamalarına olanak tanıyan bir ASP.net uygulaması oluşturduk. Şimdi sistem çok az hata ile iyi çalışıyor ve bu Muhasebe Hedefini hesaplamak için 7000'den fazla kural içeriyor. Böyle bir senaryonun sadece kodlama ile mümkün olabileceğini sanmıyorum.

Yine de böyle bir yaklaşımın sınırları vardır:

• Şirket işi hakkında mükemmel bir anlayışa sahip, yetenekli iş kullanıcılarına sahip olmanız gerekir.
• Bir İş Kuralı Motoru tarafından işlenecek kurallara dönüştürülmesi mantıklı olan tüm sabit kodlanmış koşulları belirlemek için tüm sistemin (bizim durumumuzda bir Veri Ambarı) aranmasında önemli bir iş yükü vardır. Ayrıca, bu ilk şablonların İşletme Kullanıcıları tarafından tamamen anlaşılabilir olmasına da özen göstermeliydik.
• Çakışan iş kurallarının tespitine yönelik algoritmaların uygulandığı, kural yazımı için kullanılan bir uygulamaya sahip olmanız gerekir. Aksi takdirde, artık hiç kimsenin aldığı sonuçları anlamadığı büyük bir karmaşa ile karşılaşırsınız. Özel İş Kuralı Motoru gibi genel bir bileşende bir hatanız olduğunda, daha önce çalışan şeylerin şimdi de çalıştığından emin olmak için hata ayıklamak ve kapsamlı testler yapmak çok zor olabilir.

Bu konuyla ilgili daha fazla ayrıntı yazdığım bir gönderide bulunabilir: http://dwhbp.com/post/2011/10/30/Implementing-a-Business-Rule-Engine.aspx

Genel olarak, bir İş Kuralı Motorlarını kullanmanın en büyük avantajı, kullanıcıların bir şeyi değiştirmeye ihtiyaç duyduklarında BT departmanına gitmeye gerek kalmadan İş Kuralı tanımları ve yazımı üzerinde kontrolü geri almalarına izin vermesidir. Ayrıca, artık daha fazla katma değerli şeyler oluşturmaya odaklanabilen BT geliştirme ekiplerine göre iş yükünü de azaltır.

Alkış,

Nicolae

"İki ucu keskin kılıç" olduğunu fark ettiğim tek nokta:

mantığı teknik olmayan personelin ellerine teslim etmek

Teknik olmayan tarafta bir veya iki multidisipliner dahiniz olduğunda, bu çalışmanın harika olduğunu gördüm, ancak aynı zamanda şişkinliğe, daha fazla hataya ve genel olarak geliştirme / bakım maliyetine 4 kat yol açan teknik eksikliğini de gördüm.

Bu nedenle kullanıcı tabanınızı ciddiye almanız gerekir.

Alex Papadimoulis'in makalesinin oldukça aydınlatıcı olduğunu düşündüm: http://thedailywtf.com/articles/soft_coding.aspx

Kapsamlı değil ama bazı iyi noktaları var.

Kural Motorunun ne zaman kullanılmayacağına dair HARİKA makale ... (ve ne zaman kullanılacağına dair) ....

http://www.jessrules.com/guidelines.shtml

Diğer bir seçenek ise, bir sonuç elde etmek için herhangi bir sırayla yalnızca bir kez uygulanan doğrusal bir kurallar kümesine sahipseniz, harika bir arayüz oluşturmak ve geliştiricilerin bu yeni kuralları yazmasını ve dağıtmasını sağlamaktır. Avantajı, inanılmaz derecede hızlı olmasıdır, çünkü normalde hazırda bekletme oturumunu VEYA jdbc oturumunu ve ayrıca herhangi bir parametreyi geçersiniz, böylece tüm uygulama verilerinize verimli bir şekilde erişebilirsiniz. Bir olgu listesi ile, sistemi gerçekten yavaşlatabilecek çok sayıda döngü / eşleştirme olabilir ..... Bir kural motorundan kaçınmanın ve dinamik olarak dağıtılabilmenin başka bir yoludur (evet, harika kurallarımız veritabanı ve özyineleme yoktu .... ya kuralı karşıladı ya da uymadı). Bu sadece başka bir seçenektir ..... ah ve bir başka avantajı da, gelen geliştiriciler için kural sözdizimini öğrenmemektir.

Bu gerçekten bağlamınıza bağlıdır. Kural motorunun yeri vardır ve bir proje üzerinde kural motoru gerektirmeyen çok basitleştirilmiş durumlar için dinamik olarak dağıtmak isteyebileceğiniz kurallarınız varsa, yukarıdakiler başka bir seçenektir.

Basit bir kural kümeniz varsa ve onun yerine harika bir arayüze sahipseniz, TEMEL OLARAK bir kural motoru KULLANMAYIN ..... dinamik olarak konuşlandırılabilir ve ekibinize katılan yeni geliştiricilerin onu drools dilinden daha hızlı öğrenebilmesi gibi. (Ama bu benim görüşüm)

Tecrübelerime göre, kural motorları aşağıdakiler doğru olduğunda en iyi şekilde çalışır:

1. Sorun alanınız için iyi tanımlanmış doktrin
2. Girişlerinizin çoğunu yönlendirmeye yardımcı olmak için yüksek kaliteli (tercihen otomatikleştirilmiş) veriler
3. Konu uzmanlarına erişim
4. Uzman sistemler oluşturma deneyimi olan yazılım geliştiriciler

Bu dört özellikten herhangi biri eksikse, yine de sizin için çalışan bir kural motoru bulabilirsiniz, ancak bunu 1 eksikle her denediğimde başım belaya girer.

Bu kesinlikle iyi bir başlangıç. Kural motorlarıyla ilgili diğer bir şey de, bazı şeylerin iyi anlaşılmış, belirleyici ve açık olmasıdır. Bordro stopajı böyledir (ya da öyle olmak için kullanılır). Sen olabilir bir kural motoru tarafından çözüleceğini kuralları gibi bunu ifade, ancak değerlerin oldukça basit tablo olarak aynı kurallar ifade edebilmiştir.

Dolayısıyla, iş akışı motorları, kalıcı verilere sahip olacak daha uzun vadeli bir süreci ifade ederken iyidir. Kural motorları benzer bir şey yapabilir, ancak çok fazla karmaşıklık yapmanız gerekir.

Kural motorları, karmaşık bilgi tabanlarınız olduğunda ve aramaya ihtiyacınız olduğunda iyidir. Kural motorları karmaşık sorunları çözebilir ve değişen durumlara hızla uyarlanabilir, ancak temel uygulamaya çok fazla karmaşıklık getirir.

Birçok karar algoritması, gerçek bir kural motorunun ima ettiği karmaşıklık olmadan basit bir tabloya dayalı program olarak ifade edilecek kadar basittir.

Açık kaynak olarak Drools gibi iş kuralları motorlarını veya LiveRules gibi Ticari Kurallar Motorunu şiddetle tavsiye ederim .

• Doğası gereği değişken olan çok sayıda iş politikanız olduğunda, çekirdek teknoloji kodunun bu bölümünü korumak çok zordur.
• Kural motoru, çerçeve için büyük bir esneklik sağlar ve değiştirilmesi ve dağıtılması kolaydır.
• Kural motorları her yerde kullanılmaz, ancak düzenli olarak değişikliklerin kaçınılmaz olduğu çok sayıda politikanız olduğunda kullanılması gerekir.

Şu gibi bazı noktaları gerçekten anlamıyorum:
a) iş adamlarının işi çok iyi anlaması gerekiyor veya;
b) iş adamları hakkındaki anlaşmazlıkların kuralı bilmesine gerek yoktur.

Benim için, sadece BRE'ye dokunan bir insan olarak ， BRE'nin faydası, sistemin iş değişikliğine adapte olmasına izin vermek, dolayısıyla değişime uyum sağlamaya odaklanmak.
X zamanında oluşturulan kuralın y zamanında kurulan kuraldan aşağıdakilerden farklı olması fark eder mi:
a) iş adamları işi anlamıyor mu, yoksa;
b) iş adamları kuralları anlamıyor mu?