4

私たちの e コマース ドメインには、ネストされた配列を使用してモデル化されたエンティティの階層があります。これは、ドメイン駆動設計の原則を使用して行います (Eric Evans が説明)。当社の e コマース ドメインの中心的な概念は次のとおりです。

  • 取引所があり、それぞれがサービスと支払いの両方を持っている契約。サービスには、各サービスを説明する機能があります。

この階層モデルにより、契約全体 (または契約) の一部として複数の契約 (つまり、交換) を持つものを含め、どんなに複雑であっても、あらゆる契約を表現できます。

Drools はそのような階層オブジェクト モデルをサポートしていませんか? 次のように、オブジェクト モデルを配列のないフラット オブジェクト モデル ( Drools Expert ドキュメントの「Fires HAVE Rooms」および「Sprinklers HAVE Rooms」の例など) に変換する必要がありますか?

  • 契約。
  • それぞれが単一のコントラクトを持つ 取引所。
  • ServicesとPayments。それぞれに 1 つの Exchange があります。
  • Features、それぞれに 1 つの Service があります。

このように、階層オブジェクト モデルをアトミック アサーションを持つフラット オブジェクト モデルに変換することが、Drools でサポートされ、最適に機能するというのは正しいでしょうか? Drools は、ファクトおよびサブコレクション内のファクトに対する LHS 条件を含むルールをサポートしていないようです。

もしそうなら、Drools がより階層的なオブジェクト モデルをサポートしないのはなぜですか? Drools が AI の世界 (オブジェクト指向の世界ではない) から来ているためでしょうか。この世界では、一次論理がすべての事実をアトミックな主語-述語-値ステートメントとして表現し、エンティティ オブジェクトがアイデンティティ、値を持つオブジェクト指向の世界ではありません。オブジェクトには ID がなく、エンティティ オブジェクトは他のエンティティ オブジェクトと値オブジェクトで構成されていますか?

4

2 に答える 2

1

任意の Java オブジェクト モデルに対してルールを定義できます。

ドキュメントでは、説明から気を散らさないように、おもちゃの問題に基づいた例を提供しています。Drools がより複雑なモデルを処理できないからではありません。マニュアルをもう少し読むと、「contains」やアキュムレータなどの構文を使用してリストを処理する例が表示されます。

これをどのようにモデル化するかはあなた次第です。契約、交換、サービス、支払い、および機能を、相互に参照する個別のファクトとして挿入できます。または、Exchange のリスト、サービスのリストなどを含む複雑な契約ファクトを挿入することもできます。

どちらが適切に機能するかは、チェーンがほとんどないコントラクトでルールが一致するかどうか、または機能の変更や支払いファクトの挿入などにルールを反応させたいかどうかによって異なります。

于 2013-02-10T15:08:59.887 に答える
0

Drools は任意の Pojo で動作するため、オブジェクトのネストされたアクセサーがサポートされています。ただし、ネストされたアクセサーには反応性がありません。

機能要求として、リスナーを挿入することにより、ネストされたアクセサーの反応性の追加を開始することができます。それは自明ではない作品ですが、非常に興味深いものになるでしょう。

于 2013-02-13T21:09:01.430 に答える