규칙 엔진의 기능에 관심이 있습니다.
- 비즈니스 중심 로직을 시작하고 반복
- “비즈니스 사용자”가 개발자가 아니라 해당 규칙을 실제로 수정하도록합니다.
- 일반적인 비즈니스 규칙 이해
또한 규칙 엔진을 사용하면 응용 프로그램의 품질에 영향을 줍니까?
수천 대의 컴퓨터를 사용하여 1 대 머신 설정 대 아키텍처 대 멀티 티어 클라우드 기반 분산 아키텍처에 배포하는 경우 규칙 엔진 사용이 변경됩니까? 어떻게 다를까요?
답변
비 기술적 인 직원이 비즈니스 규칙을 수정하기위한 인터페이스를 공개할지 여부에 대한 결정은 프로젝트 목표, 프로젝트 비용, 프로젝트 수명 및 알려진 요소에 대한 알려진 비율과 같은 여러 요인에 따라 크게 달라집니다. 계획.
예를 들어, 아무도 규칙 인터페이스를 사용하지 않을 것이라고 믿었다면 아마도 구현하지 않을 것입니다. 그러나 변경이 빈번하고 다른 최종 사용자가 다른 규칙이 적용될 것으로 예상 할만한 이유가 있다면 그러한 기능을 만드는 작업을 고려할 것입니다.
프로젝트 에서이 작업을 수행하기로 결정했으며 기능이 널리 사용되기까지 몇 년이 걸렸습니다. 나는 우리가 결국 스스로 물건을 커스터마이즈하고 싶어하는 최종 사용자를 가질 것이라고 생각했기 때문에 우리는이 기능을 조각으로 구현했습니다.
개발자 나 관리자 같은 특정 사람들 만 사용할 수있는 것으로 시작되었습니다. 인터페이스는 어수선했지만, 무엇을하고 있는지 알고 있다면 사용할 수 있습니다. 그러나 제품이 완성 될 때까지 규칙 엔진 백엔드 로직이 유용 해졌으며, 디자인 팀은 고객에게 아름다운 사용자 인터페이스를 제공했습니다.
내가 다르게 행동한다면, 학습 곡선이 높기 때문에 다른 데이터베이스 아키텍처를 선택할 수 있습니다. 요컨대, 초기에 그것을 구축하면 코드로 돌아가서 모든 역동적 규칙을 포함하도록 리팩토링하지 않고도 많은 고객이 기능에 직면하게되었습니다.
답변
이 작업을 수행하려면 규칙을 표현하기 위해 도메인 별 언어를 만들고 요청한 경우이를 수정하기 위해 비즈 유형에 UI를 제공 할 수 있습니다. 그런 다음 Haskell, Lisp 또는 Erlang과 같은 기능적 언어를 사용하여 규칙을 평가하십시오.
대규모 병렬 처리가 필요한 경우 동시성을 매우 잘 수행하는 Erlang을 사용합니다. Erlang을 사용하면 1 노드에서 100 이상으로 확장 할 수 있습니다.
규칙을 데이터 세트에 적용되는 대수라고 생각하면 코드에서 필요한 것을 논리 화하고 자신 (또는 관리자)에게 올바른지 증명하는 것이 훨씬 쉬워집니다. 이것은 기능적 언어가 유리하게 작동하는 장소 중 하나입니다.
답변
WF (Windows Workflow Foundation)를 기반으로 응용 프로그램을 작성했습니다. 내 상사 (DBA)는 WF가 동시성을 계획하지 않고도 멀티 스레딩을 수행 할 수 있다고 확신했습니다. 기억은 철저히 나뉘어졌지만 너무 많은 문제가 있었는데 단지 몇 단락으로 설명 할 수 없으며 질문과 약간 관련이 있습니다 … 그래서 계속합니다.
BL을 반복하는 기능 :
WF가이를 잘 수행합니다.
비 기술자들이 “앱을 구축”할 수 있도록 허용 :
WF는 아키텍처가 작동하고 비 기술자들이 기술적 한계를 이해하는 경우이를 잘 수행합니다.
일반적으로 비즈니스 규칙을 이해하는 기능 :
공유 지점이 워크 플로를 자동화 할 수있는 것과 같은 몇 가지 기본 기능을 수행 할 수있는 추가 기능이 있습니다. 나는이 품목들에 들어 가지 않았다.
소프트웨어 영역의 품질 :
Mediocre. WF는 우리의 목적을 위해 잘 작동하지 않았지만 시스템이 잘못 설계되었고 내 손이 묶였습니다.
응용 프로그램 속도 :
느린. 학습 곡선은 개발자와 최종 사용자 모두에게 매우 가파 릅니다. WF가 메모리를 분리하는 방식 (앱 도메인은 내가 기억한다면)은 교차 스레드 통신을 만들었고, 뮤텍스 및 기타 스레딩 개념은 번거 롭거나 단순히 작동하지 않습니다.
궁극적으로 WF가 구현 된 방식으로 실패했음을 증명하는 프로토 타입을 작성했습니다. 일반적인 멀티 스레딩으로 교체했습니다. 성능 및 코드 가독성이 향상되었습니다. 이것이 나의 첫번째 직업적인 WF 신청 이었기 때문에 이것을 한 알의 소금과 함께 가져 가라.
비 기술자들은 프로그래머가 필요없이 실질적으로 모든 것이 가능하다고 생각할 수있다. 이는 BL의 “더미 다운 (dummy down)”에 잠재적으로 큰 부정적이다. 이와 관련된 사회 학적 문제로 인해 프로젝트가 중단되었습니다.
되돌아 가서 내 방식으로 할 수 있다면 : 데코레이터 패턴을 통해 달성 된 전통적인 나사 가공과 BL 성형을 사용하십시오 . 이러한 기술을 사용한 개념 증명을 작성했으며 잘 작동했습니다. 그리고 BL 맵핑은 SIMPLE UI로 랩핑되어야합니다.
업데이트
동시성 문제를 해결할 때 쓴 오래된 게시물을 발견했습니다. 이 코드는 표지 아래에서 수행되는 작업 (WF 추상화의 전체 목적을 상실 함)을 이해하지 않고 병렬 워크 플로에서 “hello world”를 인쇄하는 방법을 보여줍니다. MSDN 중재자는 병렬 활동이 실제로 순차적 인 방법에 대한 개괄적 인 개요를 설명합니다. 그는 기본적으로이 기본 사항을 수행하기 위해 “전체 설명서를 읽어야합니다”로 결론을 내립니다. http://social.msdn.microsoft.com/Forums/en/windowsworkflowfoundation/thread/8a1fa165-ad5c-4cd2-b489-7ea5fc31fed8
행운을 빕니다.
답변
Java 코드에서 Oracle 규칙 엔진으로의 완벽한 연결 경험이 없었습니다. 이 중 일부는 규칙 작성자의 경험 부족으로 인한 것일 수 있지만 이것이 제가 직면 한 것입니다.
- 우리는 규칙 엔진을 상태 비 저장 장치로 구현했습니다. 호출자는 모든 매개 변수를 수집하여 평가를 위해 엔진에 전달해야했습니다. 즉, 규칙에 다른 데이터 필드가 필요한 경우 모든 클라이언트를 업데이트해야했습니다. 이는 소비자와 독립적으로 규칙을 업데이트 할 수 있다는 선전적인 이점을 부정했습니다.
- 엔진이 SOAP WSDL을 공개했지만 규칙 세트에서 자동 생성되었습니다. 규칙을 조금만 변경하면 소비자와의 계약이 깨질 수 있습니다.
- 엔진은 규칙을 평가하는 데 능숙했지만 평가에 실패한 이유를 알려주는 것은 끔찍합니다. 유익한 오류 메시지를 사용자에게 다시 제공하는 것은 어렵습니다.
- WSDL이 일반 소비에 적합하지 않았습니다. 가장 간단한 룰 세트에는 룰베이스의 내부를 노출하는 14 페이지 WSDL이 있습니다. 비즈니스 친화적 인 외관을 제공하기 위해 SOA 변환 계층을 앞에 배치해야했습니다. 따라서 100 % 신뢰할 수있는 로컬 라이브러리를 호출하는 대신 루프에 두 개의 추가 서버가있었습니다. 그것은 최소한 신뢰성에 추가되지 않습니다. 또한 규칙 서명을 변경하면 코드를 업데이트하는 서로 다른 세 팀이 필요했습니다. 민첩한 내 정의가 아닙니다!
- 규칙 세트에 추가가 필요할 때마다 WSDL을 업데이트해야하므로 클라이언트가 더 이상이를 이해하지 못했습니다. 이로 인해 v2, v3.에 대한 새로운 SOAP 엔드 포인트가 추가되었습니다. 방화벽 규칙을 업데이트해야하는 영향을 미쳤습니다.
- 규칙은 간단한 규칙에서는 쉽게 이해할 수 있지만 복잡한 규칙에서는 거의 불투명 한 “구조적 영어”로 표현되었습니다.
- 규칙 작성 언어를 알고있는 계약자를 찾을 수 없었습니다.
- 규칙 언어는 배열, 재귀 또는 객체 방향을 구현하지 않았습니다. 어떤 경우에는 규칙을 구현하는 유일한 방법은 규칙이 VB에서 구현 된 Excel 스프레드 시트에 대한 콜 아웃을 통한 것입니다. 왜 귀찮게?
나는 규칙 엔진을 사용하는 선택이 명확하지 않다고 생각합니다. 사용하려는 엔진을 프로토 타입 한 다음 정보에 근거한 결정을 내리는 것이 좋습니다. 그들은 분명히 은색 총알이 아닙니다 …