เมื่อใดที่คุณไม่ควรใช้ Rules Engine [ปิด]

ฉันมีรายการข้อดีของการใช้ Rules Engine รวมถึงเหตุผลบางประการในการใช้สิ่งที่ฉันต้องการคือรายการเหตุผลที่คุณไม่ควรใช้ Rules Engine

สิ่งที่ดีที่สุดที่ฉันมีคือ:

เอ็นจินกฎไม่ได้มีไว้เพื่อจัดการกับเวิร์กโฟลว์หรือการดำเนินการของกระบวนการจริงๆและไม่ใช่กลไกเวิร์กโฟลว์หรือเครื่องมือการจัดการกระบวนการที่ออกแบบมาเพื่อทำกฎ

เหตุผลสำคัญอื่นใดที่คุณไม่ควรใช้?

ฉันรู้สึกประหม่ามากเมื่อเห็นผู้คนใช้ชุดกฎขนาดใหญ่มาก (เช่นตามลำดับของกฎหลายพันกฎในชุดกฎเดียว) นี้มักจะเกิดขึ้นเมื่อเครื่องยนต์กฎเป็นเดี่ยวนั่งอยู่ในใจกลางขององค์กรด้วยความหวังว่ากฎการรักษาแห้งจะทำให้พวกเขาสามารถเข้าถึงแอพพลิเคหลายอย่างที่พวกเขาต้องการ ฉันจะท้าทายใครก็ได้ที่จะบอกฉันว่าเครื่องมือกฎ Rete ที่มีกฎมากมายนั้นเป็นที่เข้าใจกันดี ฉันไม่ทราบเครื่องมือใด ๆ ที่สามารถตรวจสอบเพื่อให้แน่ใจว่าไม่มีข้อขัดแย้ง

ฉันคิดว่ากฎการแบ่งพาร์ติชันที่กำหนดให้มีขนาดเล็กเป็นตัวเลือกที่ดีกว่า แง่มุมอาจเป็นวิธีการแบ่งปันกฎทั่วไปที่กำหนดระหว่างวัตถุต่างๆ

ฉันชอบแนวทางที่ง่ายกว่าและขับเคลื่อนด้วยข้อมูลมากกว่าทุกที่ที่เป็นไปได้

ฉันจะยกตัวอย่าง 2 ตัวอย่างจากประสบการณ์ส่วนตัวที่การใช้ Rules Engine เป็นความคิดที่ไม่ดีบางทีนั่นอาจช่วยได้: -

1. ในโปรเจ็กต์ที่ผ่านมาฉันสังเกตเห็นว่าไฟล์กฎ (โปรเจ็กต์ใช้ Drools) มีโค้ดจาวาจำนวนมากรวมถึงลูปฟังก์ชัน ฯลฯ โดยพื้นฐานแล้วไฟล์จาวาที่ปลอมตัวเป็นไฟล์กฎ เมื่อฉันถามสถาปนิกเกี่ยวกับเหตุผลในการออกแบบของเขาฉันได้รับแจ้งว่า "กฎไม่เคยมีไว้เพื่อดูแลโดยผู้ใช้ทางธุรกิจ"

บทเรียน : เหตุผลเหล่านี้เรียกว่า "กฎทางธุรกิจ" อย่าใช้กฎเมื่อคุณไม่สามารถออกแบบระบบที่ผู้ใช้ธุรกิจสามารถดูแล / เข้าใจได้ง่าย

2. อีกกรณีหนึ่ง; โครงการใช้กฎเนื่องจากข้อกำหนดมีการกำหนด / เข้าใจไม่ดีและมีการเปลี่ยนแปลงบ่อยครั้ง วิธีแก้ปัญหาของทีมพัฒนาคือการใช้กฎอย่างกว้างขวางเพื่อหลีกเลี่ยงการใช้โค้ดบ่อยๆ

บทเรียน : ข้อกำหนดมีแนวโน้มที่จะเปลี่ยนแปลงอย่างมากในระหว่างการเปลี่ยนแปลงรุ่นแรกและไม่รับประกันการใช้กฎ ใช้กฎเมื่อธุรกิจของคุณเปลี่ยนแปลงบ่อย (ไม่ใช่ข้อกำหนด) เช่น: - ซอฟต์แวร์ที่ทำภาษีของคุณจะเปลี่ยนแปลงทุกปีเนื่องจากกฎหมายการจัดเก็บภาษีมีการเปลี่ยนแปลงและการใช้กฎเป็นแนวคิดที่ดี เว็บแอปเวอร์ชัน 1.0 จะมีการเปลี่ยนแปลงบ่อยครั้งเมื่อผู้ใช้ระบุข้อกำหนดใหม่ แต่จะคงที่เมื่อเวลาผ่านไป อย่าใช้กฎเป็นทางเลือกในการปรับใช้โค้ด

ฉันเป็นแฟนตัวยงของ Business Rules Engines เพราะมันสามารถช่วยให้ชีวิตของคุณง่ายขึ้นในฐานะโปรแกรมเมอร์ หนึ่งในประสบการณ์แรกที่ฉันได้พบขณะทำงานในโครงการคลังข้อมูลคือการค้นหา Stored Procedures ที่มีโครงสร้าง CASE ที่ซับซ้อนซึ่งทอดยาวไปทั่วทั้งหน้า มันเป็นฝันร้ายที่จะแก้จุดบกพร่องเนื่องจากเป็นเรื่องยากมากที่จะเข้าใจตรรกะที่ใช้ในโครงสร้าง CASE ที่ยาวเช่นนี้และเพื่อตรวจสอบว่าคุณมีการทับซ้อนระหว่างกฎในหน้า 1 ของรหัสและอีกกฎจากหน้าที่ 5 โดยรวมแล้วเรามี กฎดังกล่าวมากกว่า 300 กฎที่ฝังอยู่ในโค้ด

เมื่อเราได้รับข้อกำหนดการพัฒนาใหม่สำหรับสิ่งที่เรียกว่าปลายทางการบัญชีซึ่งเกี่ยวข้องกับการปฏิบัติตามกฎมากกว่า 3,000 ข้อฉันรู้ว่ามีบางอย่างที่ต้องเปลี่ยนแปลง ย้อนกลับไปตอนนั้นฉันได้ทำงานกับต้นแบบซึ่งต่อมาได้กลายเป็นผู้ปกครองของสิ่งที่ตอนนี้คือเอ็นจิน Custom Business Rule ซึ่งสามารถจัดการตัวดำเนินการมาตรฐาน SQL ทั้งหมดได้ ในตอนแรกเราใช้ Excel เป็นเครื่องมือในการเขียนและหลังจากนั้นเราได้สร้างแอปพลิเคชัน ASP.net ซึ่งจะช่วยให้ผู้ใช้ทางธุรกิจสามารถกำหนดกฎเกณฑ์ทางธุรกิจของตนเองได้โดยไม่จำเป็นต้องเขียนโค้ด ขณะนี้ระบบทำงานได้ดีโดยมีข้อบกพร่องน้อยมากและมีกฎมากกว่า 7,000 รายการสำหรับการคำนวณปลายทางการบัญชีนี้ ฉันไม่คิดว่าสถานการณ์เช่นนี้จะเกิดขึ้นได้ด้วยการเข้ารหัสอย่างหนัก

อย่างไรก็ตามแนวทางดังกล่าวมีข้อ จำกัด :

• คุณต้องมีผู้ใช้ทางธุรกิจที่มีความสามารถและมีความเข้าใจในธุรกิจของ บริษัท เป็นอย่างดี
• มีภาระงานที่สำคัญในการค้นหาระบบทั้งหมด (ในกรณีของเราคือคลังข้อมูล) เพื่อกำหนดเงื่อนไขแบบฮาร์ดโค้ดทั้งหมดซึ่งเหมาะสมที่จะแปลเป็นกฎที่จะจัดการโดย Business Rule Engine นอกจากนี้เรายังต้องดูแลให้เทมเพลตเริ่มต้นเหล่านี้เข้าใจได้อย่างสมบูรณ์โดยผู้ใช้ทางธุรกิจ
• คุณต้องมีแอปพลิเคชันที่ใช้สำหรับการสร้างกฎซึ่งจะใช้อัลกอริทึมสำหรับการตรวจจับกฎทางธุรกิจที่ทับซ้อนกัน ไม่เช่นนั้นคุณจะต้องเจอกับเรื่องวุ่นวายที่ไม่มีใครเข้าใจผลลัพธ์ที่ได้รับอีกต่อไป เมื่อคุณมีจุดบกพร่องในองค์ประกอบทั่วไปเช่น Custom Business Rule Engine อาจเป็นเรื่องยากมากที่จะแก้ไขข้อบกพร่องและเกี่ยวข้องกับการทดสอบอย่างละเอียดเพื่อให้แน่ใจว่าสิ่งต่างๆที่เคยทำงานมาก่อนจะใช้ได้ผลเช่นกัน

ดูรายละเอียดเพิ่มเติมเกี่ยวกับหัวข้อนี้ได้ในโพสต์ที่ฉันเขียน: http://dwhbp.com/post/2011/10/30/Implementing-a-Business-Rule-Engine.aspx

โดยรวมแล้วข้อได้เปรียบที่ใหญ่ที่สุดของการใช้ Business Rule Engines คือช่วยให้ผู้ใช้สามารถควบคุมคำจำกัดความและการเขียนกฎธุรกิจได้โดยไม่จำเป็นต้องไปที่แผนกไอทีทุกครั้งที่ต้องแก้ไขบางสิ่ง นอกจากนี้ยังช่วยลดภาระงานของทีมพัฒนาไอทีซึ่งปัจจุบันสามารถมุ่งเน้นไปที่การสร้างสิ่งต่างๆที่มีมูลค่าเพิ่มมากขึ้น

ไชโย

Nicolae

สิ่งหนึ่งที่ฉันสังเกตเห็นว่าเป็น "ดาบสองคม" คือ:

วางตรรกะไว้ในมือของเจ้าหน้าที่ที่ไม่ใช่ด้านเทคนิค

ฉันเคยเห็นงานนี้ยอดเยี่ยมเมื่อคุณมีอัจฉริยะสหสาขาวิชาชีพหนึ่งหรือสองคนในด้านที่ไม่ใช่ด้านเทคนิค แต่ฉันยังเห็นการขาดเทคนิคที่นำไปสู่การขยายตัวข้อบกพร่องมากขึ้นและโดยทั่วไป 4 เท่าของค่าใช้จ่ายในการพัฒนา / บำรุงรักษา

ดังนั้นคุณต้องพิจารณาฐานผู้ใช้ของคุณอย่างจริงจัง

ฉันคิดว่าบทความของ Alex Papadimoulis ค่อนข้างเจาะลึก: http://thedailywtf.com/articles/soft_coding.aspx

มันไม่ครอบคลุม แต่เขามีจุดดีบางอย่าง

บทความดีๆเกี่ยวกับเวลาที่จะไม่ใช้กลไกกฎ ... (รวมถึงเวลาที่ควรใช้) ....

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

อีกทางเลือกหนึ่งคือหากคุณมีชุดกฎเชิงเส้นที่ใช้เพียงครั้งเดียวเพื่อให้ได้ผลลัพธ์คือการสร้างอินเทอร์เฟซที่น่าสนใจและให้นักพัฒนาเขียนและปรับใช้กฎใหม่เหล่านี้ ข้อดีคือมันเร็วอย่างชั่วร้ายเพราะโดยปกติคุณจะผ่านเซสชันไฮเบอร์เนตหรือเซสชัน jdbc ตลอดจนพารามิเตอร์ใด ๆ เพื่อให้คุณสามารถเข้าถึงข้อมูลแอพทั้งหมดของคุณ แต่อย่างมีประสิทธิภาพ ด้วยรายการข้อเท็จจริงอาจมีการวนซ้ำ / การจับคู่จำนวนมากที่สามารถทำให้ระบบช้าลงได้ ..... เป็นอีกวิธีหนึ่งในการหลีกเลี่ยงกลไกกฎและสามารถปรับใช้แบบไดนามิกได้ (ใช่กฎที่น่ากลัวของเราถูกปรับใช้ใน a ฐานข้อมูลและเราไม่มีการเรียกซ้ำ .... มันเป็นไปตามกฎหรือไม่) มันเป็นเพียงอีกทางเลือกหนึ่ง ..... อ้อและอีกหนึ่งประโยชน์คือไม่ได้เรียนรู้ไวยากรณ์กฎสำหรับนักพัฒนาที่เข้ามา

มันขึ้นอยู่กับบริบทของคุณจริงๆ เอ็นจินกฎมีสถานที่และด้านบนเป็นเพียงอีกทางเลือกหนึ่งหากคุณมีกฎในโปรเจ็กต์ที่คุณอาจต้องการปรับใช้แบบไดนามิกสำหรับสถานการณ์ที่เรียบง่ายมากที่ไม่ต้องใช้เอ็นจินกฎ

โดยพื้นฐานแล้วอย่าใช้เอ็นจินกฎหากคุณมีชุดกฎง่ายๆและสามารถมีอินเทอร์เฟซที่น่าสนใจแทนได้ ..... เช่นเดียวกับที่ใช้งานได้แบบไดนามิกและนักพัฒนาใหม่ที่เข้าร่วมทีมของคุณสามารถเรียนรู้ได้เร็วกว่าภาษาที่น่าเบื่อ (แต่นั่นคือความคิดของฉัน)

จากประสบการณ์ของฉันเอ็นจินกฎจะทำงานได้ดีที่สุดเมื่อสิ่งต่อไปนี้เป็นจริง:

1. หลักคำสอนที่กำหนดไว้อย่างดีสำหรับโดเมนปัญหาของคุณ
2. ข้อมูลคุณภาพสูง (โดยเฉพาะอย่างยิ่งอัตโนมัติ) เพื่อช่วยขับเคลื่อนอินพุตส่วนใหญ่ของคุณ
3. เข้าถึงผู้เชี่ยวชาญเฉพาะเรื่อง
4. นักพัฒนาซอฟต์แวร์ที่มีประสบการณ์ในการสร้างระบบผู้เชี่ยวชาญ

หากคุณลักษณะทั้งสี่นี้ขาดหายไปคุณอาจพบว่ากลไกกฎทำงานได้ดีสำหรับคุณ แต่ทุกครั้งที่ฉันลองใช้แม้จะหายไป 1 รายการฉันก็ประสบปัญหา

นั่นเป็นการเริ่มต้นที่ดีอย่างแน่นอน สิ่งอื่น ๆ ที่มีกลไกกฎก็คือมีบางสิ่งที่เข้าใจได้ดีมีการกำหนดและตรงไปตรงมา การหักภาษี ณ ที่จ่ายเป็น (หรือเคยเป็น) เช่นนั้น คุณสามารถแสดงเป็นกฎที่เอ็นจินกฎจะแก้ไขได้ แต่คุณสามารถแสดงกฎเดียวกันกับตารางค่าที่ค่อนข้างเรียบง่าย

ดังนั้นเครื่องมือเวิร์กโฟลว์จึงดีเมื่อคุณแสดงกระบวนการระยะยาวซึ่งจะมีข้อมูลถาวร เอ็นจินกฎสามารถทำสิ่งที่คล้ายกันได้ แต่คุณต้องเพิ่มความซับซ้อนมากมาย

เอ็นจินกฎเป็นสิ่งที่ดีเมื่อคุณมีฐานความรู้ที่ซับซ้อนและต้องการการค้นหา เอ็นจิ้นกฎสามารถแก้ไขปัญหาที่ซับซ้อนและสามารถปรับให้เข้ากับสถานการณ์ที่เปลี่ยนแปลงได้อย่างรวดเร็ว แต่กำหนดความซับซ้อนในการใช้งานพื้นฐาน

อัลกอริธึมการตัดสินใจหลายอย่างนั้นง่ายพอที่จะแสดงเป็นโปรแกรมที่ขับเคลื่อนด้วยตารางอย่างง่ายโดยไม่มีความซับซ้อนที่บ่งบอกโดยกลไกของกฎจริง

ฉันขอแนะนำอย่างยิ่งให้เอ็นจิ้นกฎทางธุรกิจเช่นDrools เป็นโอเพ่นซอร์สหรือเอ็นจิ้นกฎเชิงพาณิชย์เช่น LiveRules

• เมื่อคุณมีนโยบายทางธุรกิจจำนวนมากซึ่งมีความผันผวนตามธรรมชาติการรักษารหัสเทคโนโลยีหลักนั้นเป็นเรื่องยากมาก
• เอ็นจิ้นกฎให้ความยืดหยุ่นที่ดีของกรอบงานและง่ายต่อการเปลี่ยนแปลงและปรับใช้
• ไม่ควรใช้เอ็นจิ้นกฎทุกที่ แต่จำเป็นต้องใช้เมื่อคุณมีนโยบายจำนวนมากซึ่งการเปลี่ยนแปลงเป็นสิ่งที่หลีกเลี่ยงไม่ได้เป็นประจำ

ฉันไม่ค่อยเข้าใจบางประเด็นเช่น
ก) นักธุรกิจต้องเข้าใจธุรกิจเป็นอย่างดีหรือ;
b) การไม่เห็นด้วยกับนักธุรกิจไม่จำเป็นต้องรู้กฎ

สำหรับฉันในฐานะคนที่เพิ่งสัมผัสกับ BRE， ประโยชน์ของ BRE จึงเรียกได้ว่าปล่อยให้ระบบปรับตัวเข้ากับการเปลี่ยนแปลงทางธุรกิจดังนั้นจึงมุ่งเน้นไปที่การปรับตัวให้เข้ากับการเปลี่ยนแปลง
มีความสำคัญหรือไม่ว่ากฎที่ตั้งขึ้นในเวลา x จะแตกต่างจากกฎที่ตั้งขึ้นในเวลา y เนื่องจาก
ก) นักธุรกิจไม่เข้าใจธุรกิจหรือ;
b) นักธุรกิจไม่เข้าใจกฎ?