규칙 엔진 - 장점과 단점

Question

저는 소위 말하는 것을 사용하는 프로젝트를 감사하고 있습니다. 규칙 엔진.간단히 말해서 애플리케이션 코드에서 비즈니스 로직을 외부화하는 방법입니다.

이 개념은 나에게 완전히 새로운 것이며 나는 그것에 대해 꽤 회의적입니다.사람들의 이야기를 듣고 나면 빈혈 도메인 모델 지난 몇 년 동안 저는 규칙 엔진 접근 방식에 의문을 제기했습니다.나에게 그것은 도메인 모델을 약화시키는 좋은 방법처럼 보입니다.예를 들어 규칙 엔진과 상호 작용하는 Java 웹앱을 만들고 있다고 가정해 보겠습니다.그런 다음 동일한 도메인을 기반으로 하는 Android 앱을 갖고 싶다고 결정했습니다.Android 앱이 규칙 엔진과도 상호작용하기를 원하지 않는다면 이미 작성된 비즈니스 로직을 모두 놓치게 될 것입니다.

아직 경험이 없기 때문에 단지 호기심일 뿐입니다. 규칙 엔진을 사용할 때의 장단점에 대해 듣고 싶었습니다.제가 생각할 수 있는 유일한 장점은 일부 비즈니스 규칙을 변경하기 위해 전체 애플리케이션을 다시 빌드할 필요가 없다는 것입니다(그러나 실제로 그렇게 많은 변경 사항을 적용한 앱은 몇 개나 될까요?).하지만 규칙 엔진을 사용하여 문제를 해결하는 것은 마치 산탄총으로 인한 상처 위에 반창고를 붙이는 것과 같습니다.

업데이트 - 이 글을 쓴 이후, 신 마틴 파울러(Martin Fowler)는 규칙 엔진 사용에 대한 블로그.

Answer 1

내가 본 대부분의 규칙 엔진은 시스템 코드에 의해 블랙박스로 간주됩니다.도메인 모델을 구축한다면 특정 비즈니스 규칙이 도메인 모델에 고유해지기를 원할 것입니다.객체에 유효하지 않은 값이 있을 때 이를 알려주는 비즈니스 규칙입니다.이를 통해 여러 시스템이 비즈니스 논리를 복제하지 않고도 도메인 모델을 공유할 수 있습니다.각 시스템이 동일한 규칙 서비스를 사용하여 내 도메인 모델을 검증하도록 할 수 있지만 이는 내 도메인 모델을 약화시키는 것으로 보입니다(질문에서 지적한 바와 같이).왜?왜냐하면 항상 모든 시스템에 걸쳐 비즈니스 규칙을 일관되게 적용하는 대신 시스템 프로그래머에게 의존하여 비즈니스 규칙을 적용해야 하는 시기를 결정하기 때문입니다(규칙 서비스 호출을 통해).도메인 모델이 완전히 채워진 경우에는 문제가 되지 않을 수 있지만 수명 동안 도메인 모델의 값을 변경하는 사용자 인터페이스나 시스템을 처리하는 경우에는 문제가 될 수 있습니다.

또 다른 종류의 비즈니스 규칙이 있습니다.의사결정.예를 들어, 보험 회사는 신청자의 인수 위험을 분류하고 보험료를 산출해야 할 수 있습니다.이러한 유형의 비즈니스 규칙을 도메인 모델에 배치할 수 있지만 이와 같은 시나리오에 대한 중앙 집중식 결정은 일반적으로 바람직하며 실제로 서비스 지향 아키텍처에 매우 적합합니다.이는 시스템 코드가 아닌 규칙 엔진이 필요한 이유에 대한 질문을 제기합니다.규칙 엔진이 더 나은 선택이 될 수 있는 곳은 결정을 담당하는 비즈니스 규칙이 시간이 지남에 따라 변경되는 곳입니다(다른 답변에서 지적했듯이).

규칙 엔진을 사용하면 일반적으로 시스템을 다시 시작하거나 새 실행 코드를 배포하지 않고도 규칙을 변경할 수 있습니다. 공급업체로부터 어떤 약속을 받았는지에 관계없이 규칙 엔진이 완벽하더라도 비프로덕션 환경에서 변경 사항을 테스트해야 합니다. , 인간은 여전히 ​​​​규칙을 변경하고 있습니다)."데이터베이스를 사용하여 변화하는 값을 저장하면 그렇게 할 수 있다"고 생각하신다면 맞습니다.규칙 엔진은 새로운 일을 하는 마법의 상자가 아닙니다.이는 바퀴를 재발명하는 데 덜 집중할 수 있도록 더 높은 수준의 추상화를 제공하는 도구로 만들어졌습니다.많은 공급업체에서는 비즈니스 사용자가 규칙 언어를 배우는 대신 공백을 채울 수 있도록 템플릿을 만들 수 있도록 하여 한 단계 더 발전합니다.

템플릿에 대한 한 가지 주의 사항:템플릿은 최소한 규칙을 설명해야 하기 때문에 템플릿 없이 규칙을 작성하는 것보다 시간이 덜 걸릴 수 없습니다.더 높은 초기 비용을 계획합니다(데이터베이스를 사용하여 변경되는 값을 저장하는 시스템을 구축하는 것과 동일).시스템 코드에 직접 규칙 작성) - ROI는 향후 시스템 코드 유지 관리 비용을 절감하기 때문입니다.

Answer 2

빈혈 영역 모델에 대한 귀하의 우려가 유효하다고 생각합니다.

나는 내가 일하는 생산에서 잘 알려진 상업용 Rete Rules 엔진의 두 가지 응용 프로그램을 보았습니다. 나는 하나를 성공이라고 생각하고 다른 하나는 실패라고 생각합니다.

성공적인 응용 프로그램은 각각 ~ 30 가지 지점의 ~ 10 트리로 구성된 의사 결정 트리 앱입니다. 규칙 엔진에는 비즈니스 담당자가 규칙을 유지할 수있는 UI가 있습니다.

덜 성공적인 응용 프로그램에는 ~ 3000 규칙이 규칙 데이터베이스에 적용됩니다. 새로운 규칙이 추가 될 때 상충되는 규칙이 있는지는 아무도 전혀 없습니다. Rete 알고리즘에 대한 이해가 거의 없으며 제품에 대한 전문 지식은 회사를 떠났으므로 만질 수없고 보충 할 수없는 블랙 박스가되었습니다. 배포주기는 여전히 규칙 변경의 영향을받습니다. 규칙이 변경 될 때 완전한 회귀 테스트를 수행해야합니다. 기억도 문제였습니다.

나는 가볍게 밟았다. 규칙 세트의 크기가 적은 경우 위에 제공된 단순한 전자 메일 샘플과 같이 변경 사항을 쉽게 이해하기 쉽습니다. 규칙의 수가 수백 명으로 올라가면 문제가있을 수 있다고 생각합니다.

또한 규칙 엔진이 응용 프로그램에서 싱글 톤 병목 현상이되는 것에 대해 걱정합니다.

엔진 공간을 규칙하는 파티션 방법으로 객체를 사용하는 데 아무런 문제가 없습니다. 개인 규칙 엔진을 연기하는 물체에 동작을 포함시키는 것은 나에게 괜찮은 것 같습니다. 규칙 엔진이 대상의 일부가 아닌 상태가 제대로 발사 할 때 문제가 발생하면 문제가 발생합니다. 그러나 그것은 디자인이 어려운 또 다른 예일뿐입니다.

Answer 3

규칙 엔진은 특정한 경우 많은 가치를 제공 할 수 있습니다.

첫째, 많은 규칙 엔진이보다 선언적 인 방식으로 작동합니다. 매우 조잡한 예는 Awk이며, 여기서 코드 블록에 Regexes를 할당 할 수 있습니다. 파일 스캐너가 Regex를 볼 때 코드 블록이 실행됩니다.

이 경우 큰 awk 파일이 있고 또 다른 "규칙"을 추가하고 싶다면 파일의 맨 아래로 쉽게 이동하고, 재 조정 및 논리를 추가하고, 끝날 수 있음을 알 수 있습니다. 그것. 구체적으로, 많은 응용 프로그램의 경우, 다른 규칙이 수행하는 일에 특히 관심이 없으며 규칙이 서로 상호 작용하지 않습니다.

따라서 AWK 파일은 "규칙 수프"와 비슷합니다. 이 "규칙 수프"자연을 통해 사람들은 시스템에있을 수있는 다른 모든 규칙에 대해 거의 우려하지 않고 도메인에 매우 단단히 집중할 수 있습니다.

예를 들어, Frank는 총 $ 1000 이상의 주문에 관심이 있으므로 관심있는 규칙 시스템에 참여합니다. "Order.total> 1000이면 Frank에게 이메일을 보내십시오".

한편 샐리는 서해안에서 모든 주문을 원한다.

따라서이 사소한 사례에서 주문이 두 규칙을 모두 충족시킬 수 있지만 두 규칙 모두 서로 독립적이라는 것을 알 수 있습니다. 서해안에서 1200 달러의 주문은 Frank와 Sally를 모두 알립니다. 프랭크가 더 이상 걱정하지 않으면, 그는 단순히 수프에서 그의 규칙을 잡아 당길 것입니다.

많은 상황 에서이 유연성은 매우 강력 할 수 있습니다. 이 경우와 마찬가지로 간단한 규칙을 위해 최종 사용자에게 노출 될 수 있습니다. 높은 수준의 표현식과 가벼운 스크립팅을 사용합니다.

이제 복잡한 시스템에는 일어날 수있는 모든 종류의 상호 관계가 있습니다. 이것이 전체 시스템이 "규칙으로 완료되지 않은"이유입니다. 누군가, 어딘가에는 규칙이 나오지 않는 규칙을 담당 할 것입니다. 그러나 이것이 그러한 시스템이 제공 할 수있는 가치를 반드시 줄이는 것은 아닙니다.

이것은 규칙이 생성 할 수있는 데이터에 대한 규칙이 발사되는 전문가 시스템과 같은 것들에 빠지지 않고 더 간단한 규칙 시스템에 들어 가지 않습니다.

어쨌든,이 예제가 규칙 시스템이 더 큰 응용 프로그램을 강화하는 데 어떻게 도움이 될 수 있기를 바랍니다.

Answer 4

규칙 엔진에 대해 내가 본 가장 큰 전문가는 비즈니스 규칙 소유자가 프로그래머에 Onus를 넣는 대신 비즈니스 규칙을 구현할 수 있다는 것입니다. 이해 관계자로부터 지속적으로 피드백을 받고 빠른 반복을 겪고있는 민첩한 프로세스가 있더라도 사람들이 비즈니스 규칙을 구현하도록함으로써 달성 할 수있는 효율성 수준을 달성하지 못할 것입니다.

또한 규칙이 코드에 포함 된 경우 간단한 규칙 변경으로 인해 발생할 수있는 재 컴파일 리 레스트 레드 배치주기를 제거 할 때 값을 부적절하게 강조 할 수 없습니다. 축복을 빌드에 넣는 데 관여하는 여러 팀이 종종 있으며 규칙 엔진을 사용하면 그 불필요한 많은 부분을 만들 수 있습니다.

Answer 5

나는 클라이언트를 위한 규칙 엔진을 작성했습니다.가장 큰 승리는 모든 이해관계자를 포함했다는 것입니다.엔진은 쿼리를 실행(또는 재생)하고 무슨 일이 일어나고 있는지 텍스트로 설명할 수 있습니다.비즈니스 담당자는 텍스트 설명을 보고 규칙, 예외 및 기타 특수 사례의 미묘한 차이를 빠르게 지적할 수 있습니다.일단 비즈니스 측이 참여하자 그들의 의견을 쉽게 얻을 수 있었기 때문에 검증이 훨씬 더 좋아졌습니다.또한 규칙 엔진은 애플리케이션 코드 베이스의 다른 부분과 별도로 존재할 수 있으므로 애플리케이션 전체에서 사용할 수 있습니다.

단점은 일부 프로그래머가 너무 많은 것을 배우는 것을 좋아하지 않는다는 것입니다.규칙 엔진과 여기에 입력하는 규칙은 이를 구현하는 내용과 함께 다소 복잡할 수 있습니다.좋은 시스템은 아프고 뒤틀린 논리 웹(또는 종종 비논리적임)을 쉽게 처리할 수 있지만, 여러 코드를 코딩하는 것만큼 간단하지는 않습니다. if 진술(간단한 규칙 엔진 중 일부가 수행하는 작업에 관계 없음).규칙 엔진은 규칙 관계를 처리하는 도구를 제공하지만 여전히 모든 것을 마음속으로 상상할 수 있어야 합니다.가끔은 영화 속에 사는 것 같아 브라질. :)

Answer 6

(다른 모든 것과 같이)는 응용 프로그램에 따라 다릅니다. 일부 애플리케이션의 경우 (일반적으로 변경되지 않는 응용 프로그램의 경우 또는 규칙이 실제 상수에 가장 적합합니다. 즉, Eons에서 눈에 띄게 변경되지 않습니다. 예를 들어 물리적 특성 및 공식) 규칙 엔진을 사용하는 것은 의미가 없습니다. 추가 복잡성을 소개하고 개발자가 더 큰 기술 세트를 가져야합니다.

다른 응용 프로그램의 경우 정말 좋은 생각입니다. 예를 들어 주문 처리 (인보이스 발행에서 처리 통화 거래에 이르기까지 주문)를 받으십시오. 이제 매번 새로운 요구 사항 (예 : 판매 세)을 이행 해야하는 일부 관련 법률 또는 코드 (사법적 인 의미)가 1 분 변경됩니다. , 클래식). 갑자기 갑자기 판매 세에 대해 생각 해야하는이 새로운 상황으로 기존 응용 프로그램을 강요하려고하는 대신, 그렇지 않은 것처럼, 잠재적으로 대규모로 막히지 않고 규칙 세트를 조정하는 것이 더 쉽습니다. 코드 세트.

그런 다음 지방 정부의 차기 수정안은 특정 기준 내에서 모든 판매를보고해야합니다. 결국 당신은 당신이 돌아 서서 관리하기가 매우 어려워지고 다른 모든 사람들에게 영향을 미치지 않고 규칙 중 하나의 효과를 되돌리고 싶을 때 매우 복잡한 코드로 끝납니다 ...

Answer 7

지금까지 모든 사람들은 규칙 엔진에 대해 매우 긍정적 이었지만 독자에게 조심해야합니다. 문제가 조금 더 복잡해지면 전체 규칙 엔진이 더 강력한 언어보다 부적합하거나 훨씬 더 복잡해 졌다는 것을 갑자기 알 수 있습니다. 또한 많은 문제의 경우 규칙 엔진은 조건 평가의 런타임 및 메모리 풋 프린트를 크게 줄이는 속성을 쉽게 감지 할 수 없습니다. 의존성 주입 프레임 워크 또는보다 역동적 인 프로그래밍 언어보다 규칙 엔진을 선호하는 상황은 상대적으로 적습니다.

Answer 8

"그러나 실제로, 얼마나 많은 앱이 실제로 많은 변화를 가지고 있습니까?"

솔직히 말해서, 내가 작업 한 모든 앱은 배포 후 심각한 워크 플로우 및/또는 개념에서 논리 변경을 거쳤습니다. "유지 보수"프로그래밍의 가장 큰 이유입니다 ...

현실은 모든 것을 앞에 생각할 수 없으므로 민첩한 프로세스의 이유입니다. 또한 BA는 테스트에서 발견 될 때까지 항상 중요한 것을 놓치는 것 같습니다.

규칙 엔진은 비즈니스 논리를 프레젠테이션 및 스토리지에서 진정으로 분리하도록 강요합니다. 또한 올바른 엔진을 사용하는 경우 BA는 필요에 따라 논리를 추가하고 제거 할 수 있습니다. Chris Marasti-Georg가 말했듯이, 그것은 BA에 onus를 넣습니다. 그러나 그 이상으로, BA는 그들이 요구하는 것을 정확하게 얻을 수 있습니다.

Answer 9

규칙 엔진은 피할 수있는 경우 사용자 정의 빌드를 수행하지 않아도되는 구성 가능한 응용 프로그램에서 승리합니다. 또한 큰 규칙과 알고리즘의 큰 기반을 중앙 집중화하는 데 능숙합니다. 은퇴합니다 큰 규칙 세트와 신속하게 일치하는 데 효율적입니다.

Answer 10

이미 많은 좋은 답변이 있지만 몇 가지를 추가하고 싶었습니다.

1. 복잡성에 대한 결정을 자동화 할 때 중요한 것은 관련된 논리를 실행하기보다는 관리 능력이 빠르게됩니다. 규칙 엔진은 이에 도움이되지 않습니다. 비즈니스 규칙 관리 시스템의 규칙 관리 기능에 대해 생각해야합니다. 대부분의 상업용 및 오픈 소스 규칙 엔진 엔진은 저장소가있는 규칙 관리 시스템으로 발전하여 규칙 사용, 버전 작성 등에 대한보고 등의 규칙 세트로 구성된 규칙 세트로 구성된 규칙 저장소의 저장소는 관리가 훨씬 쉽게 관리 할 수있는 일관성 규칙 세트로 구성됩니다. 수천 줄의 코드 또는 규칙 수프.
2. 선언적, 규칙 기반 접근법을 사용하는 방법에는 여러 가지가 있습니다. UI를 관리하기 위해 규칙을 사용하거나 프로세스 정의의 일부로 매우 효과적 일 수 있습니다. 그러나 규칙 접근법의 가장 귀중한 사용은 비즈니스 결정을 자동화하고이를 입력하고 규칙을 실행하며 답을 반환하는 느슨하게 결합 된 의사 결정 서비스로 제공하는 것입니다. "이 고객에게 좋은 신용 위험이있는 것"또는 "이 고객 에게이 고객에게 제공해야 할 할인 또는"현재이 고객에게 가장 적합한 크로스 판매는 무엇입니까? 이러한 의사 결정 서비스는 규칙 관리 시스템을 사용하여 매우 효과적으로 구축 될 수 있으며 시간이 지남에 따라 분석을 쉽게 통합 할 수 있습니다.

Answer 11

규칙, 프로세스 및 데이터 엔진 (일명 데이터베이스)이 본질적으로 유사하다고 생각합니다. 그러나 어떤 이유로 든 우리는 Blackboxing the Persistence 서브 시스템이 나쁘다고 말하지 않습니다.

둘째, 내 POV에서 빈혈 모델은 가벼운 모델이 아닙니다. 구현 행동의 경우, 그것은 가벼운 것입니다. 행동 자체. 도메인 모델 객체에서 사용 가능한 동작을 설명하는 실제 메소드는 객체 자체가 수행 할 필요가 없습니다.

Answer 12

규칙 엔진에서의 경험에서 가장 큰 복잡성은 다음과 같습니다.

1. OOP POV에서 그것은 선언적 언어로 작성된 리팩토러와 테스트 규칙에 영향을 미치는 코드를 리팩토링하는 데 영향을 미치는 진정한 고통입니다.
2. 종종 우리는 규칙의 실행 순서에 대해 항상 생각해야합니다.
3. 일부 사소한 변경으로 인해 생산 버그로 이어지는 규칙의 잘못된 동작이 유발 될 수 있습니다. 실제로 테스트를 앞두고 모든 사례를 다루는 것이 항상 가능하지는 않습니다.
4. 다른 것들에 사용되는 객체를 돌연변이하는 규칙은 복잡성을 증가시켜 개발자가 단계로 나누게합니다.