ユーザー定義のビジネスルールはどこに保存しますか？
たとえば、部門や従業員を中心に動作するアプリケーションがあるとします。各部門には、どの部門にどの従業員を割り当てるかを定義する一連のルールがあります。たとえば、システムは、年数の経験や話し言葉などのいくつかのプロパティに基づいて、従業員を特定の部門に自動的に割り当てます。トリッキーな部分は、これらのルールが事前定義されていないことです。つまり、アプリケーションユーザーがそれらのルールを作成、削除、および変更できるようにしたいので、ソースコードにルールを配置できません。
これどうやってするの？
私はあなたがすでにそのような機能を見て、おそらく使用したと確信しています：すべてのまともなメールクライアントは、ユーザーがいくつかのルールテンプレートを選択し、いくつかの条件とパラメーターを追加して、新しいメールが到着するたびにルールが自動的に実行されるようにして、カスタムフィルタールールを定義することをユーザーに許可します。したがって、これは実際には、そのようなシステムを実装する方法の1つ（多く）です。
そのため、はい、カスタムルールとロジックがシステムに含まれていることで特別なことはありません。ただし、これには、ユーザーがルールを実装するための標準またはドメイン固有のプログラミング言語を使用して、本格的な組み込みインタープリターから選択できるいくつかの単純なパラメーター化されたルールから始まり、幅広いオプションと自由度があります。多分いくつかの一般的なルールエンジンに基づいています。
自由度は、通常、開発努力とユーザーの学習曲線の急勾配に相関します。したがって、これには万能のソリューションはありません。ユーザーが必要とする柔軟性の量を分析する必要があります。「より柔軟」は必ずしも「学習するのが難しい」ことを意味するため、必ずしも優れているとは限りません。ユーザーがビジネスロジックにある程度の柔軟性を求めている場合は、ユーザーが実際に必要とする柔軟性と、複雑なルールとロジックを自分で定義する方法を学ぶために費やす努力について調べてください。
これとの妥協は必然的にあります。複雑なルールをその場で定義するための無制限の柔軟性をユーザーに提供したい場合、アプリケーション内にドメイン固有のプログラミング言語を作成する必要があります。これを解析します。これは小さな仕事ではありません。
ただし、この程度の制御は過剰である可能性があります。ユーザーは、次の機能を持つコンテンツである可能性があります。
- 属性を定義します（例：HAS_5_YEARS_EXPERIENCEまたはSPEAKS_SPANISHまたはIS_CONVICTED_FELON）
- 各従業員にこれらの属性をいくつでも割り当てます
- 各部門のカスタムルールを指定します（例：REQUIRES：SPEAKS_SPANISHまたはFORBIDDEN：IS_CONVICTED_FELON）
これははるかに簡単な作業です。
Drools（Java）のようなルールエンジンを使用します。ルールエンジンには、基本的に2つの目的があります。 1つは、保存したルールを実行する（つまり、従業員が所属する部署を決定する）です。 Tqo：実行時にルールを変更する方法を提供します。ルールエンジンは、定義により動的です。これはあなたのシナリオにぴったり合っているようです！
Droolsのようなルールエンジンの使用についてはすでに説明しました。
構成の大部分をエンドユーザーに任せると、プログラミングメンテナンスに比べて典型的な欠点があります。
- 変更は実行中の本番システムに直接影響します。
- バージョン管理はありません。
- デザインはアドホックです。
- ドキュメントはありません。
- エンドユーザーは、ソフトウェアシステムの「ロジック」に慣れていません。
したがって、十分かつ特別な注意深い開発が必要です。
詳細なストーリー：詳細なユーザーインターフェイスを使用して、詳細な設計を行います。
技術的な要件、技術的な概念を持っている場合にのみ、正しいツールを探します。したがって、開発時間は作業負荷部品に比例して分散されます。
警告：データがドキュメントのような場合、複数のデータベーステーブルに複雑なデータ（数百のグラフノード）を格納しないでください。そのようなデータをXMLとして単一のテーブル（JAXB）に格納することをお勧めします。 JPAを使用する場合でも、すべてを分散させるのではなく、グラフ間を移動できる方が良いです。
別のメモ：そのようなソフトウェアは、通常、計画的にのみassistである必要があり、必ずしも規範的ではありません。多くの場合、クライアントは最適化、高速化、公平化を望んでいます。これは、手動による例外はおそらく処理され、文書化可能であることを意味します。
ルールは [〜＃〜] owl [〜＃〜] + [〜＃〜] rdf [〜＃〜] に保存できます。 W3C。 OWLは記述ロジックを表すことができます（これを参照 Ian Horrocksによるプレゼンテーション 、および "Grimoris Antoniou、Paul Groth、Frank van Harmelen、およびRinke Hoekstraによる"セマンティックWebプライマー " 。では、従業員、部門、および職務資格に関するオントロジーを定義できます。また、このオントロジー内で推論できます。たとえば、プロパティとこれらのプロパティの意味を定義したり、さまざまな部門の要件を定義したり、従業員の資格を保存したりできます。
知識表現に関するある程度の知識があれば、プロパティの変更と追加、部門のルールの変更などを行うことができます。
次に、既存のOWL推論（ Apache Jena 、 OpenLink Virtuoso 、 AllegroGraph RDF store など）を使用できます。および ペレット ）
推論システム、定義したオントロジー、および従業員と部門のデータベースを使用して、部門xでの作業に必要なすべてのプロパティを満たす従業員のクラスを見つけることができます。
セマンティックWebファミリーのツールには、OWL推論ツール、RDFトリプルストア（OWLはRDFとして保存されることが多い）、およびナレッジベースエディターが存在します。