ルールエンジンの使用は、アプリケーションの設計、実装、およびパフォーマンスにどのように影響しますか？

ルールエンジンの機能に興味があります。

• ビジネス駆動型ロジックの起動と反復
• 開発者ではなく、これらのルールの実際の変更を「ビジネスユーザー」に実行させる
• 一般的なビジネスルールを理解する

また、ルールエンジンの使用はアプリケーションの品質に影響しますか？

1台のマシンのセットアップ、アーキテクチャ、数千台のマシンを使用する多層クラウドベースの分散アーキテクチャに展開する場合、ルールエンジンの使用は変わりますか？どう違いますか？

ビジネスルールを変更するために非技術者向けのインターフェイスを公開するかどうかの決定は、プロジェクトの目標、プロジェクトのコスト、プロジェクトの存続期間、および既知の既知の未知の比率など、いくつかの要因に大きく依存します事業。

たとえば、誰もルールインターフェイスを使用しないと信じている場合、おそらく実装をオプトアウトします。ただし、変更が頻繁に発生し、さまざまなエンドユーザーがさまざまなルールが導入されることを期待すると信じる理由がある場合は、そのような機能の構築に取り組むことを検討します。

プロジェクトでこれを行うことを選択しましたが、この機能が広く使用されるまでに何年もかかりました。最終的にはエンドユーザーが自分自身でカスタマイズしたいと思うので、この機能を分割して実装しました。

開発者や管理者などの特定の人々だけが使用できるものとして始まりました。インターフェースは不格好でしたが、自分が何をしているかを知っていれば使用できました。しかし、製品が完成に近づいている頃には、ルールエンジンのバックエンドロジックが役に立ち、設計チームは顧客向けの美しいユーザーインターフェイスを提供しました。

別の方法で行う場合は、学習曲線が高いという理由だけで別のデータベースアーキテクチャを選択する可能性があります。しかし、要するに、早い段階でそれを構築することで、コードに戻ってすべての動的ルールを含めるためにリファクタリングしなければならないという頭痛の種がなく、顧客が直面する多くの機能につながりました。

これを行う場合、ドメイン固有言語を作成してルールを表現し、必要に応じてビジネスタイプにUIを変更して変更することもできます。次に、関数型言語（Haskell、Lisp、Erlangなど）を使用してルールを評価します。

大規模な並列処理が必要な場合、並行処理を非常にうまく行うErlangを使用します。Erlangを使用すると、1ノードから100以上に適切に拡張できます。

ルールをデータセットに適用される代数と考えると、コードに必要なものを論理的に考え出し、それが正しいことを自分（またはマネージャー）に証明するのがはるかに簡単になります。これは、関数型言語が好意的に機能する場所の1つです。

WF（windows workflow Foundation）に基づいたアプリケーションを作成しました。私の上司（DBA）は、WFが並行性を計画する必要なくマルチスレッドを実行できると確信していました。メモリは完全に分割されていましたが、非常に多くの問題があったため、数段落で説明することはできず、あなたの質問にわずかに関連しているだけなので、続けます。

BLを反復処理する機能：
WFはこれをうまく行います。
非技術者が「アプリを構築する」ことを許可する：
アーキテクチャが機能し、非技術者が技術的な制限を理解している場合、WFはこれをうまく行います。
一般的なビジネスルールを理解
する機能： SharePointがワークフローを自動化できるように、基本的なことを実行できるアドインがいくつかあります。私はこれらのアイテムには入りませんでした。
ソフトウェアの品質の現実：
平凡。WFは私たちの目的に対してはうまく機能しませんでしたが、システムの設計が悪く、手が縛られていました。
アプリケーションの速度：
スロー。学習曲線は、開発者にとってもエンドユーザーにとっても非常に急です。WF分離メモリ（思い出すとアプリドメイン）がクロススレッド通信、ミューテックス、およびその他のスレッド化の概念を混乱させたり、まったく機能しなかったりする方法。

最終的に、私はWFが実装された方法で失敗することを証明するプロトタイプを作成しました。一般的なマルチスレッドに置き換えました。パフォーマンスとコードの可読性が上がりました。これは私の最初のプロフェッショナルWFアプリケーションであったため、これを一粒の塩で取ります。

ノンテクは、プログラマーを必要とせず、BLの「ダミーダウン」全体に対して潜在的に大きなネガティブな可能性があり、事実上すべてが可能であると信じるようになります。これに関連する社会学的問題がプロジェクトを殺しました。

戻って自分のやり方でできるなら、伝統的なスレッディングとデコレーターパターンを介して達成されたBLモールディングを使用します。 これらの技術を使用した概念実証を作成し、うまく機能しました。 また、BLマッピングはシンプルUIでラップする必要があります。
更新
並行性の問題を処理しているときに書いた古い投稿を見つけました。このコードは、並列ワークフローでの「hello world」の印刷が、カバーの下で何が行われているのかを理解しないと機能しないことを示しています（WF抽象化の目的全体を無効にします）。MSDNモデレーターは、並列アクティビティが実際にシーケンシャルである方法の概要を説明します。彼は基本的に、この基本的なことをするために「マニュアル全体を読む必要がある」と結論づけています。 http://social.msdn.microsoft.com/Forums/en/windowsworkflowfoundation/thread/8a1fa165-ad5c-4cd2-b489-7ea5fc31fed8

幸運を。

私は、JavaコードからOracleルールエンジンに接続するのに完璧な経験はありません。これのいくつかは、ルール作成者の経験不足によるかもしれませんが、これは私が直面したことです。

• ルールエンジンをステートレスデバイスとして実装しました。呼び出し元は、すべてのパラメーターを収集して、評価のためにエンジンに渡す必要がありました。これは、ルールが別のデータフィールドを必要とする場合、すべてのクライアントを更新する必要があることを意味します。これにより、消費者とは無関係にルールを更新できるという利点が否定されました。
• エンジンはSOAP WSDLを公開しましたが、ルールセットから自動生成されました。規則を少し変更すると、消費者との契約が破られます。
• エンジンはルールの評価には優れていましたが、評価が失敗した理由を伝えるのはひどいものでした。有益なエラーメッセージをユーザーにフィードバックすることは困難でした。
• WSDLは一般的な消費には適していませんでした。最も単純なルールセットには14ページのWSDLがあり、ルールベースの内部を公開していました。ビジネスに適した外観を提供するために、SOA翻訳レイヤーを前面に配置する必要がありました。そのため、100％信頼性の高いローカルライブラリを呼び出す代わりに、ループ内に2つの余分なサーバーがありました。それは少なくとも信頼性に追加されません。さらに、ルールの署名の変更には、3つの異なるチームがコードを更新する必要がありました。私のアジャイルの定義ではありません！
• ルールセットに追加が必要なときはいつでも、WSDLを更新する必要があり、クライアントはそれを理解できなくなりました。これにより、v2、v3の新しいSOAPエンドポイントが追加され、ファイアウォールルールを更新する必要があるというノックオン効果がありました。
• 規則は「構造化された英語」で表現され、単純な規則では容易に理解できるが、複雑な規則では不透明に近い。
• ルールのオーサリング言語を知っている請負業者を見つけることはできませんでした。
• ルール言語は、配列、再帰、オブジェクト指向を実装していませんでした。ある場合には、ルールを実装する唯一の方法は、VBでルールが実装されたExcelスプレッドシートへのコールアウトを介することでした。なぜわざわざ？

ルールエンジンを使用する（またはしない）選択肢は明確ではないと思います。使用するエンジンのプロトタイプを作成してから、情報に基づいた決定を下すことをお勧めします。それらは確かに特効薬ではありません...