Drools로 비즈니스 규칙 엔진 구축 - SMEople의 힘
게시 됨: 2022-03-11소프트웨어 개발 분야에서 일할 때 가장 놀라운 점 중 하나는 다양한 산업 분야에서 일할 수 있다는 것입니다. 특히 컨설턴트라면 더욱 그렇습니다. 한 산업 내에서 일하는 동안 배우는 대부분의 소프트웨어 개발 기술은 다른 산업, 회사, 프로젝트 및 틈새 시장으로 직접 이전할 수 있습니다.
저는 데이터베이스 디자인, 디자인 패턴, GUI 레이아웃, 이벤트 관리 등과 같은 주제에 대해 말하고 있습니다. 물론 특정 산업, 회사 또는 프로젝트에 특정한 주제가 있습니다.
SME가 IT를 만나 지식 이전이 시작됩니다.
여기서 SME(Subject Matter Expert)가 필요합니다. SME는 일반적으로 프로젝트의 설계 단계에 많이 참여합니다.
SME는 오랫동안 업계에서 일해 왔으며 용어를 알고 있으며 코딩 이면의 비즈니스 논리를 이해하고 있습니다. SME는 소프트웨어 개발에 대해 어느 정도 이해하고 있을 수 있지만 이것이 프로젝트 성공에 필요한 것은 아닙니다.
많은 프로젝트의 경우 소프트웨어 개발자가 비즈니스 로직을 잘 이해하지 못한다면 성공적인 소프트웨어 애플리케이션을 완성하기가 상대적으로 어려울 것입니다. 지식 이전에 소요되는 시간은 프로젝트의 복잡성에 따라 크게 달라집니다.
애자일 접근 방식을 취하고 프로젝트의 개발 단계 전반에 걸쳐 하나 이상의 SME를 사용할 수 있다고 가정하면 프로젝트의 모든 단계에서 지식 이전이 계속됩니다.
완전한 지식 이전이 불가능하다면?
산업 및 프로젝트에 따라 SME가 완전한 지식 이전을 제공하는 것이 불가능할 수 있습니다.
예를 들어 SME가 25년 경력의 의사이고 프로젝트를 완료하는 데 6개월이 있다고 상상해 보십시오. 또는 40년의 경험을 가진 생물학자인 SME를 상상해 보십시오. 이러한 수준의 지식은 소프트웨어 개발 프로젝트를 위한 현실적인 시간 프레임으로 단순히 이전될 수 없습니다.
그러나 지식 영역이 동적이라면 어떻게 될까요?
일반적으로 소프트웨어는 시간이나 기능에 따라 정해진 일정에 따라 출시됩니다. 그러나 일부 산업의 비즈니스 규칙은 훨씬 더 자주 변경됩니다.
대부분의 경우 산업 변화에 발맞추기 위해 필요한 만큼 자주 소프트웨어를 출시하는 것이 실현 가능하지 않을 수 있습니다. 비즈니스 규칙 엔진 내에서 비즈니스 규칙을 외부화하는 기능을 갖는 것은 이러한 시나리오에서 의미가 있을 수 있습니다. 변화를 견딜 수 있는 소프트웨어 프로젝트의 능력은 궁극적인 장기적 성공을 보장하는 데 큰 도움이 될 것입니다.
규칙 엔진은 언제 어디서 의미가 있습니까?
많은 소프트웨어 프로젝트에서 완전한 지식 이전이 발생하고 비즈니스 로직이 C# 또는 Java와 같은 컴퓨터 언어로 코딩되는 것이 가능합니다.
그러나 특정 주제에 대한 이해의 양이 너무 많거나 비즈니스 규칙이 너무 많이 변경되어 프로그래머가 아닌 사람이 비즈니스 로직에 직접 액세스하는 것이 더 합리적인 프로젝트의 하위 집합이 있습니다. 이것은 이 튜토리얼의 주제입니다. 이를 염두에 두고 규칙 엔진에 대해 자세히 논의해 보겠습니다.
비즈니스 규칙 엔진이란 무엇입니까?
규칙 엔진은 비즈니스 규칙을 실행하기 위한 도구입니다. 비즈니스 규칙은 사실과 조건문으로 구성됩니다. 기존 비즈니스 논리에 나타나는 모든 "if-then" 문은 비즈니스 규칙으로 간주됩니다.
예를 들어 , 직원이 5일 이상 연속으로 병가를 내고 의사의 진단서 를 가지고 있지 않은 경우에는 이를 기록해야 합니다. 비즈니스 동료가 6개월 이상 연락하지 않았고 그 기간 동안 구매도 하지 않았다면 이제 그들에게 따뜻한 이메일을 보내야 할 것입니다. 환자가 높은 체온, 시력 문제가 있고 녹내장의 가족력이 있는 경우 추가 MRI 또는 기타 검사 를 요청할 때가 될 수 있습니다.
중소기업은 비즈니스 규칙을 어떻게 작성합니까?
SME가 Java, C# 또는 다른 프로그래밍 언어를 배우기를 기대하는 대신 IT는 비즈니스 규칙을 표현할 수 있는 미니 언어를 만듭니다. 이러한 규칙의 구성 요소는 쿼리할 수 있는 사실로 구성됩니다. 산업/실무 분야별 사실의 몇 가지 예는 다음과 같습니다.
- 인적 자원: 급여, 직위, 관리자, 회사 재직 기간
- 의료: 체온, 혈압, 현재 복용 중인 약물
- 재무: 현재 주가, 52주 최고/최저가, P/E 비율, 다음 실적 발표일
기본적으로 비즈니스 결정을 내리는 데 필요한 정보는 SME가 간소화된 방식으로 사용할 수 있어야 합니다.
이 규칙은 어떻게 생겼습니까?
이 규칙 엔진 튜토리얼의 나머지 부분에서는 www.drools.org에서 찾을 수 있고 JBoss 프로젝트인 오픈 소스 Java 기반 규칙 엔진인 Drools를 사용할 것입니다. Drools에서 규칙은 Java 코드로 작성되며 다음과 같은 구조를 갖습니다.
import 문은 다음으로 이동합니다.
rule “Name of rule” when “The if” part of the business logic goes here. then The “then” part of the business logic goes here. end침과 작업 기억
Drools는 작업 기억이라는 개념을 사용합니다.
응용 프로그램 코드는 SME가 이러한 사실을 쿼리하는 규칙을 작성할 수 있도록 적절한 사실을 작업 메모리에 로드하는 역할을 합니다. 규칙 엔진을 최고 속도로 계속 실행하려면 애플리케이션 비즈니스 로직과 관련된 사실만 작업 메모리에 로드해야 합니다.
예를 들어, 응용 프로그램이 고객의 대출 승인 여부를 결정하는 경우 관련 사실에는 급여, 신용 점수 및 미지급 대출이 포함됩니다. 관련이 없는 사실에는 요일 또는 성별이 포함됩니다.
규칙 평가
Drools 작업 메모리에 규칙과 사실이 로드되면 규칙의 "그때" 부분에 따라 규칙이 평가됩니다. "then" 부분이 true로 평가되면 규칙의 "when" 부분이 실행됩니다.
일반적으로 모든 규칙은 한 번에 평가되지만 규칙을 함께 그룹화하고 그룹별로 평가할 수 있습니다. 규칙의 "then" 부분은 작업 메모리의 내용을 변경할 수 있습니다. 이런 일이 발생하면 Drools는 모든 규칙을 재평가하여 이제 true로 평가되는 규칙이 있는지 확인합니다. 그렇다면 "언제" 부분이 실행됩니다.
규칙 평가의 이러한 재귀적 특성은 축복이 될 수도 있고 저주가 될 수도 있습니다. 따라서 이 아키텍처를 염두에 두고 규칙을 만들어야 합니다.
Drools 규칙의 "If" 측면
Drools에서 사실은 객체로 표현됩니다. 개체 유형의 존재 여부를 쿼리할 수 있습니다. 또한 개체의 속성도 쿼리할 수 있습니다.
다음은 몇 가지 예입니다.
직원의 소득이 100,000 이상인지 확인합니다.
Employee(salary > 100000)환자의 콜레스테롤 수치가 200 이상이고 리피토를 복용 중인지 확인합니다.
Patient(cholesterol > 200, medications.contains(“lipitor”))주식 가격이 연간 최고가의 1% 이내인지 확인합니다.
Stock(price >= (yearHigh * .99))쿼리 결합
복잡한 비즈니스 로직을 작성할 때 비즈니스 규칙은 부울 연산자 AND, OR 및 NOT을 사용하여 쿼리를 결합하고 괄호를 사용하여 중첩할 수 있습니다.
예를 들어:
$75,000 미만을 버는 관리자 또는 $100,000 미만을 버는 이사가 있는지 확인하십시오.
Employee(position.Equals(“Manager”),salary<75000) OR Employee(position.Equals(“Directory”),salary<100000)여러 객체 유형 사용
지금까지의 모든 예제는 직원 또는 환자와 같은 단일 개체 유형을 기반으로 했습니다. 그러나 Drools를 사용하면 여러 개체 유형을 기반으로 쿼리할 수 있습니다.
예를 들어:
고객의 급여가 $50,000 이상이고 파산 신청을 하지 않았는지 확인합니다.
Customer(salary>50000) AND not exists Bankruptcy()규칙의 "그때" 측면
규칙의 "그때" 부분은 규칙의 "언제" 부분에 최소한 하나의 결과가 있을 때 일어날 일을 결정합니다.
Drools에서 Java로 작성할 수 있는 모든 것은 규칙의 "then" 부분에 작성할 수 있습니다. 그러나 규칙을 보다 쉽게 재사용할 수 있도록 하려면 일반적으로 규칙 내에 I/O, 흐름 제어 코드 또는 일반 실행 코드를 배치하지 않는 것이 좋습니다.
대안으로, 규칙의 "then" 부분을 사용하여 작업 기억을 수정할 수 있습니다. 일반적인 관행은 규칙이 참으로 평가될 때 작업 메모리에 사실을 삽입하는 것입니다.
예를 들어:
rule “LoanApproved” when Customer(credit>700) && not exist LoanOutstanding() then insert(new LoanApproval()) end규칙이 참으로 평가된 때를 어떻게 알 수 있습니까?
모든 규칙이 실행된 후 애플리케이션은 어떤 규칙이 true로 평가되는지 알아야 합니다. 규칙이 true로 평가될 때 작업 메모리에 개체를 삽입하는 경우 해당 개체에 대해 작업 메모리를 쿼리하는 코드를 작성할 수 있습니다.
위의 예에서 모든 규칙이 실행된 후 LoanApproval() 객체가 작업 메모리에 있는지 확인하기 위한 쿼리를 만들 수 있습니다.
query "GetLoanApproval " $result: LoanApproval() end비즈니스 규칙 엔진은 애플리케이션과 어떻게 상호 작용합니까?
일반적인 애플리케이션에는 비즈니스 로직, GUI, I/O 및 제어 코드의 흐름이 포함됩니다.
예를 들어, 애플리케이션은 다음과 같이 사용자 요청을 처리할 수 있습니다.
GUI ? Flow Control ? I/O ? Business Logic ? I/O ? Flow Control ? GUI규칙 엔진을 포함하면 이 프로세스에 몇 가지 단계가 추가됩니다.
GUI ? Flow Control ? I/O ? Create Rules Engine Session ? Add Facts to Working Memory ? Fire Rules ? Determine which rules have evaluated true ? I/O ? Flow Control ? GUISME는 규칙을 어떻게 사용합니까?
규칙 생성, 편집 및 삭제
SME가 규칙을 사용하려면 사용자 친화적인 GUI가 필요합니다. 일부 비즈니스 규칙 엔진은 이러한 인터페이스와 함께 제공됩니다.
예를 들어, Drools는 사용자에게 친숙한 두 개의 GUI와 함께 제공됩니다. 첫 번째는 스프레드시트와 유사하며 SME가 실제 코드를 작성하지 않고도 규칙을 만들 수 있습니다. 두 번째 GUI를 사용하면 보다 복잡한 비즈니스 로직을 작성할 수 있습니다.
이 두 GUI는 간단한 조건을 입력하는 데 도움이 될 수 있지만 비즈니스 로직이 더 복잡해지면 작동하지 않습니다. 이 경우 사용자 지정 GUI를 만들어야 합니다.
SME 맞춤형 GUI의 요소
SME가 효율적으로 작업하려면 다음 기능을 사용하여 사용자 지정 GUI를 만드는 것이 좋습니다.
- 구문 검사기 – "구문 확인" 버튼은 Drools 코드를 호출하여 가능한 오류와 해당 줄 번호를 확인할 수 있습니다.
- 끌어서 놓기 – SME가 사용 가능한 개체 및 속성을 기억하도록 요구하는 대신 끌어서 놓을 수 있는 선택 목록을 제공하는 것이 좋습니다.
- 웹 인터페이스 – 씬 클라이언트 인터페이스는 배포 문제 없이 중소기업에서 사용할 수 있습니다. GUI에 추가 기능과 일반적인 유지 관리가 필요하기 때문에 이 기능이 유용할 것입니다.
- 규칙 테스터 – 전체 애플리케이션과 상호 작용하지 않고 개별 규칙을 테스트할 수 있는 기능이 있으면 SME 생산성이 크게 향상됩니다. SME GUI가 사실을 확인한 다음 개별 규칙을 실행하도록 허용합니다.
규칙은 어디에 저장해야 합니까?
Drools에는 일반적으로 규칙을 저장하는 두 가지 방법이 있습니다. Drools는 일반적으로 확장자가 .drl인 파일 기반 규칙을 사용하여 즉시 사용할 수 있습니다.
규칙 수가 적을 때 잘 작동합니다. 규칙 수가 늘어남에 따라 데이터베이스를 사용하고 싶을 것입니다. 데이터베이스에서 규칙을 저장하고 검색하려면 더 많은 작업이 필요하지만 훨씬 더 관리하기 쉬운 아키텍처를 제공해야 합니다.
이 규칙 엔진 튜토리얼은 Drools Rules Language의 아주 작은 부분만을 다루었습니다. 전체 설명은 공식 참조 문서를 참조하십시오.
규칙 엔진을 사용하기로 한 결정은 가볍게 내려서는 안 됩니다. 규칙 엔진을 사용하면 SME가 애플리케이션을 더 확장할 수 있지만 개발, 테스트 및 배포가 더 복잡해집니다. 이 주제에 대한 추가 고려 사항은 다음 지침을 검토하는 것이 좋습니다.
이제 우리는 좀 더 흥미로운 것을 계속해서 보여드릴 수 있습니다. 대부분의 Toptal 블로그 독자들이 익숙하게 여길 사용 사례인 Drools가 실제로 작동하는 간단한 예입니다.
실제 시나리오에서 Drool 사용
높은 수준의 소프트웨어 개발 인재를 제공하는 선두 업체인 Toptal은 현재 지원자 추적 소프트웨어를 사용하여 지원자를 채용 프로세스의 다양한 단계로 안내합니다. 다음은 이 프로세스의 단순화된 시각적 흐름도입니다.
현재, 지원자가 고용 프로세스를 계속할지 여부를 결정하는 비즈니스 로직은 소프트웨어에 하드 코딩되어 있습니다. 인적 자원은 비즈니스 논리를 변경해야 할 때마다 IT를 참여시켜야 합니다. 그들은 소프트웨어 실행 방식을 직접 변경할 수 있는 기능을 원합니다.
지원자 추적 소프트웨어는 채용 프로세스의 각 결정 지점에서 HR 제공 규칙을 실행하도록 수정됩니다. HR에는 초기 입력, 온라인 시험 완료 또는 여러 가지 요인으로 인해 상태가 변경된 구직자를 나타내는 '후보' 개체가 있습니다. Candidate 개체에는 경험, 시험 점수, 면접 점수 등을 나타내는 필드가 있습니다.
다음 예에서는 고려할 수 있는 단순화된 규칙 집합을 제공합니다. 배포되지 않았으며 4개의 상호 연결된 규칙으로 구성된 간단한 예일 뿐입니다.
- 제출됨 -> 테스트 중
- 시험 -> 면접
- 면접 -> 프로젝트
- 프로젝트 -> 고용
제출됨 -> 테스트 중
현재 클라이언트 요구 사항을 기반으로 HR은 후보자가 온라인 테스트 일정을 잡아야 하는지 여부를 결정하는 규칙을 작성하려고 합니다.
Rule “Schedule For Testing” when $candidate: Candidate(status=='Submitted',yrsExperience >= 10, skill(name=='Java', yrsExperience>=5) or Skill(name=='C#', yrsExperience>=5)) then $candidate.setStatus('Testing'); end시험 -> 면접
응시자는 온라인 시험에 응시한 후 점수를 평가해야 합니다. HR도 이 규칙을 제어하기를 원합니다. 소프트웨어 개발 이론, 문제 해결 및 구문을 이해하는 응시자의 능력을 테스트하는 온라인 시험입니다. HR은 어떤 점수 조합으로 후보자가 기술 면접을 고려할 수 있는지 결정하려고 합니다.
Rule “Schedule For Interview” when $candidate: Candidate(status=='Testing', testScore(theory>.8 && syntax>.6 && problemSolving>.8); then $candidate.setStatus('Interview'); end면접 -> 프로젝트
기술 면접은 자신의 경험에 대해 말하고, 문제 해결 질문에 답하고, 일반적으로 의사 소통하는 능력을 테스트하는 후보자의 능력을 테스트합니다. HR은 기술 면접의 합격 점수를 결정하는 규칙을 작성합니다.
Rule “Schedule For Project” when $candidate: Candidate(status=='Interview', interviewScore(speakExperience>.9 && problemSolving>.8 && communication>.9 ); then $candidate.setStatus('Project'); end프로젝트 -> 고용
기술 면접을 통과한 후보자는 오프라인 프로그래밍 프로젝트를 받게 됩니다. 그들은 프로젝트를 제출하고 완성도, 아키텍처 및 GUI로 평가됩니다.
Rule “Schedule For Hiring” when $candidate: Candidate(status=='Project', projectScore(completeness>.8 && architecture>.9 && gui>.7 ); then $candidate.setStatus('Hiring'); end보시다시피, 이 기본 예도 HR에 다양한 가능성을 제공하고 운영을 간소화할 수 있습니다. HR이 프로세스에 IT를 포함시키지 않고도 규칙을 변경할 수 있다는 사실은 필연적으로 시간을 절약하고 심사 프로세스를 가속화할 것입니다.
규칙을 즉석에서 변경할 수 있으므로 HR 부서도 훨씬 더 유연하게 대처할 수 있습니다. 예를 들어 HR은 다른 매개변수를 설정하여 선택 프로세스를 확장하거나 제한할 수 있습니다.
올바른 상자를 모두 체크한 후보자가 너무 많으면 몇 분 안에 기준을 높여 후보자의 수를 줄일 수 있습니다. 또는 프로세스에서 모든 요구 사항을 충족하는 후보자가 거의 또는 전혀 생성되지 않는 경우 HR은 적절한 수의 후보자가 요구 사항을 충족할 때까지 보다 관련성 높은 기술로 초점을 전환하여 일부 표준을 줄이거나 삭제할 수 있습니다.