규칙 엔진 사용의 장점과이를 사용하는 몇 가지 이유에 대한 꽤 괜찮은 목록이 있습니다. 필요한 것은 규칙 엔진을 사용하지 않아야하는 이유 목록입니다.
지금까지 내가 가진 최고는 다음과 같습니다.
규칙 엔진은 실제로 워크 플로 또는 프로세스 실행을 처리하기위한 것이 아니며 규칙을 수행하도록 설계된 워크 플로 엔진 또는 프로세스 관리 도구도 아닙니다.
사용하지 말아야하는 다른 큰 이유가 있습니까?
답변:
사람들이 매우 큰 규칙 집합을 사용하는 것을 보면 매우 긴장됩니다 (예 : 단일 규칙 집합에있는 수천 개의 규칙). 규칙을 DRY로 유지하면 규칙 을 필요로하는 많은 앱에서 액세스 할 수 있기를 바라며 규칙 엔진이 기업의 중심에있는 싱글 톤일 때 종종 발생 합니다. 나는 많은 규칙을 가진 Rete 규칙 엔진이 잘 이해되고 있다고 누구에게 말하지 않을 것입니다. 충돌이 없는지 확인할 수있는 도구를 알지 못합니다.
나는 그들을 작게 유지하기위한 분할 규칙 세트가 더 나은 선택이라고 생각한다. Aspect는 여러 객체간에 공통 규칙 세트를 공유하는 방법이 될 수 있습니다.
가능하면 더 간단하고 데이터 중심적인 접근 방식을 선호합니다.
규칙 엔진을 사용하는 것이 나쁜 생각 인 개인적인 경험에서 두 가지 예를 들어 보겠습니다.
Lesson : 이유 때문에 "비즈니스 룰"이라고 불리는데, 비즈니스 사용자가 쉽게 유지 / 이해할 수있는 시스템을 설계 할 수 없을 때는 룰을 사용하지 마십시오.
교훈 : 요구 사항은 초기 릴리스 변경 중에 많이 변경되는 경향이 있으며 규칙 사용을 보증하지 않습니다. 비즈니스가 자주 변경 될 때 규칙을 사용하십시오 (요구 사항이 아님). 예 :-세법이 변경되고 규칙 사용이 변경됨에 따라 세금을 수행하는 소프트웨어가 매년 변경됩니다. 웹 앱의 릴리스 1.0은 사용자가 새로운 요구 사항을 식별함에 따라 자주 변경되지만 시간이 지남에 따라 안정화됩니다. 코드 배포의 대안으로 규칙을 사용하지 마십시오.
저는 비즈니스 규칙 엔진의 열렬한 팬입니다. 프로그래머로서의 삶을 훨씬 더 쉽게 만드는 데 도움이 될 수 있기 때문입니다. 데이터웨어 하우스 프로젝트에서 작업하면서 경험 한 첫 번째 경험 중 하나는 전체 페이지에 걸쳐있는 복잡한 CASE 구조를 포함하는 저장 프로 시저를 찾는 것이 었습니다. 이렇게 긴 CASE 구조에 적용된 로직을 이해하고 코드 1 페이지의 규칙과 5 페이지의 다른 규칙이 겹치는 지 확인하기가 매우 어려웠 기 때문에 디버그하는 것은 악몽이었습니다. 코드에 포함 된 300 개 이상의 규칙.
3000 개 이상의 규칙을 다루는 회계 대상이라는 새로운 개발 요구 사항을 받았을 때 변경해야 할 사항이 있다는 것을 알았습니다. 그 당시 저는 나중에 모든 SQL 표준 연산자를 처리 할 수있는 Custom Business Rule 엔진의 부모가되는 프로토 타입을 작업했습니다. 처음에는 Excel을 저작 도구로 사용했고 나중에는 비즈니스 사용자가 코드를 작성할 필요없이 자신의 비즈니스 규칙을 정의 할 수있는 ASP.net 응용 프로그램을 만들었습니다. 이제 시스템은 버그가 거의없이 잘 작동하며이 회계 대상을 계산하기위한 7000 개 이상의 규칙을 포함합니다. 나는 그러한 시나리오가 단지 하드 코딩으로 가능했을 것이라고 생각하지 않습니다.
그러나 이러한 접근 방식에는 한계가 있습니다.
이 주제에 대한 자세한 내용은 내가 작성한 게시물에서 찾을 수 있습니다. http://dwhbp.com/post/2011/10/30/Implementing-a-Business-Rule-Engine.aspx
전반적으로 비즈니스 규칙 엔진 사용의 가장 큰 장점은 사용자가 무언가를 수정해야 할 때마다 IT 부서로 이동하지 않고도 비즈니스 규칙 정의 및 작성을 다시 제어 할 수 있다는 것입니다. 또한 더 많은 부가가치가있는 물건을 만드는 데 집중할 수있는 IT 개발 팀의 워크로드를 줄여줍니다.
건배,
니콜라에
내가 "양날의 칼"이라는 것을 알아 챘던 것은 :
비 기술 직원의 손에 논리 배치
비 기술적 인 측면에서 한두 명의 다 분야 천재가있을 때이 작업이 훌륭하다는 것을 보았지만 기술이 부족하여 부풀어 오르고 더 많은 버그가 발생하며 일반적으로 개발 / 유지 보수 비용이 4 배 증가하는 것을 보았습니다.
따라서 사용자 기반을 진지하게 고려해야합니다.
Alex Papadimoulis의 기사가 매우 통찰력이 있다고 생각했습니다. http://thedailywtf.com/articles/soft_coding.aspx
포괄적 인 것은 아니지만 좋은 점이 있습니다.
규칙 엔진을 사용하지 않을 때에 대한 훌륭한 기사 ... (사용할 때뿐만 아니라) ....
http://www.jessrules.com/guidelines.shtml
또 다른 옵션은 결과를 얻기 위해 어떤 순서로든 한 번만 적용되는 선형 규칙 집합이있는 경우 그루비 인터페이스를 만들고 개발자가 이러한 새 규칙을 작성하고 배포하도록하는 것입니다. 장점은 일반적으로 최대 절전 모드 세션 또는 jdbc 세션과 모든 매개 변수를 전달하므로 모든 앱 데이터에 효율적으로 액세스 할 수 있기 때문에 매우 빠르다는 것입니다. 팩트 목록을 사용하면 실제로 시스템 속도를 늦출 수있는 많은 루프 / 매칭이있을 수 있습니다 ..... 규칙 엔진을 피하고 동적으로 배포 할 수있는 또 다른 방법입니다 (예, 그루비 규칙은 데이터베이스이고 우리는 재귀가 없었습니다 .... 규칙을 충족했거나 그렇지 않았습니다). 그것은 또 다른 옵션 일뿐입니다 ..... 오 그리고 또 하나의 이점은 들어오는 개발자를위한 규칙 구문을 배우지 않는다는 것입니다.
그것은 정말로 당신의 상황에 달려 있습니다. 규칙 엔진에는 그 자리가 있으며 위는 규칙 엔진이 필요하지 않은 매우 단순화 된 상황에 대해 동적으로 배포하려는 프로젝트에 규칙이있는 경우 다른 옵션 일뿐입니다.
기본적으로 간단한 규칙 집합이 있고 대신 멋진 인터페이스를 가질 수있는 경우 규칙 엔진을 사용하지 마십시오. 동적으로 배포 할 수 있고 팀에 합류하는 새로운 개발자가 잠꼬대 언어보다 빠르게 배울 수 있습니다.
내 경험상 규칙 엔진은 다음이 참일 때 가장 잘 작동합니다.
이 네 가지 특성 중 하나라도 빠진 경우에도 규칙 엔진이 효과가 있다는 것을 알 수 있지만 하나라도 빠진 상태로 시도 할 때마다 문제가 발생합니다.
그것은 확실히 좋은 시작입니다. 규칙 엔진의 다른 점은 어떤 것들은 잘 이해되고 결정적이며 간단하다는 것입니다. 급여 원천 징수는 이와 같습니다 (또는 사용하기 위해 사용). 당신은 수있는 룰 엔진에 의해 해결 될 것입니다 규칙으로 표현하지만 값의 비교적 간단한 테이블과 같은 규칙을 표현할 수 있습니다.
따라서 워크 플로우 엔진은 지속적인 데이터를 보유 할 장기적인 프로세스를 표현할 때 유용합니다. 규칙 엔진은 비슷한 작업을 수행 할 수 있지만 많은 복잡성을 추가해야합니다.
규칙 엔진은 복잡한 지식 기반이 있고 검색이 필요할 때 유용합니다. 규칙 엔진은 복잡한 문제를 해결할 수 있고 변화하는 상황에 빠르게 적응할 수 있지만 기본 구현에 많은 복잡성을 부과합니다.
많은 의사 결정 알고리즘은 실제 규칙 엔진이 암시하는 복잡성없이 간단한 테이블 기반 프로그램으로 표현할 수있을만큼 간단합니다.
Drools와 같은 비즈니스 규칙 엔진 을 오픈 소스로 사용 하거나 상용 규칙 엔진 ( 예 : LiveRules)을 강력히 권장 합니다.