ルールエンジン - 長所と短所

疑問点

と呼ばれるものを使用しているプロジェクトを監査しています。 ルール エンジン . 簡単に言うと、アプリケーション コードからビジネス ロジックを外部化する方法です。

このコンセプトは私にとってまったく新しいもので、かなり懐疑的です。人々が 貧弱なドメイン モデル について話すのを聞いてから、私はルールエンジンのアプローチに疑問を感じています。私には、ルールエンジンはドメインモデルを弱体化させる素晴らしい方法のように思えるのです。例えば、私がルールエンジンと対話するJavaのWebアプリケーションを作っているとします。そして、同じドメインに基づいたAndroidアプリを持つことにしました。Android アプリがルール エンジンと同様に対話することを望んでいない限り、すでに書かれたビジネス ロジックを見逃すことになります。

ルール エンジンを使用した経験がないので、ルール エンジンを使用する利点と欠点について聞きたいと思います。私が思いつく唯一の長所は、ビジネス ルールを変更するためだけにアプリケーション全体を再構築する必要がないことです (しかし、実際、それほど多くの変更があるアプリケーションがどれほどあるでしょうか?)。しかし、この問題を解決するためにルール エンジンを使用することは、ショットガンの傷にバンドエイドを貼るようなものだと思います。

UPDATE - これを書いてから、神であるMartin Fowlerは、次のように述べています。 ルール エンジンの使用についてブログで述べています。 .

どのように解決するのですか？

私が見てきたほとんどのルールエンジンは、システムコードによってブラックボックスと見なされています。もし私がドメイン モデルを構築するとしたら、おそらく特定のビジネス ルールをドメイン モデルに内在させたいと思うでしょう。たとえば、オブジェクトに無効な値がある場合に教えてくれるビジネス ルールなどです。これにより、ビジネスロジックを重複させることなく、複数のシステムでドメインモデルを共有することができます。各システムに同じルールサービスを使わせてドメインモデルを検証することもできますが、これは（質問で指摘されたように）ドメインモデルを弱めることになるように思われます。なぜでしょうか？なぜなら、私のビジネスルールをすべてのシステムで常に一貫して適用するのではなく、ビジネスルールをいつ適用するかを（ルールサービスを呼び出すことで）システムプログラマーに依存することになるからです。ドメインモデルが完全に組み込まれた状態で提供される場合は問題ないかもしれませんが、ドメインモデルの値をその生涯にわたって変更するユーザーインターフェイスやシステムを扱っている場合は、問題になる可能性があります。

ビジネスルールの別のクラスとして、意思決定があります。例えば、保険会社が申込者を引き受ける際にリスクを分類し、保険料を算出する必要があるとします。このようなタイプのビジネスルールはドメインモデルに置くことができますが、このようなシナリオのための集中的な決定は通常望ましく、実際、サービス指向アーキテクチャに非常によく適合しています。ここで、なぜシステムコードではなくルールエンジンなのかという疑問が湧いてきます。ルールエンジンがより良い選択である可能性がある場所は、（他の回答が指摘したように）決定を担当するビジネスルールが時間の経過とともに変化する場合です。

ルール エンジンでは通常、システムを再起動したり、新しい実行可能コードを展開したりせずにルールを変更できます (ベンダーからどんな約束をされたとしても、ルール エンジンが完璧であっても、人間はまだルールを変更しているので、非生産環境で変更をテストしていることを確認してください)。ルール・エンジンが完璧であっても、人間はルールを変更してしまうからです。ルール・エンジンは、何か新しいことをする魔法の箱ではありません。 より高い抽象度を提供するツールであるため、車輪の再発明にはあまり集中できないのです。多くのベンダーはこれをさらに進めて、ビジネス ユーザーがルール言語を学ぶ代わりに空白を埋められるように、テンプレートを作成できるようにしています。

テンプレートは、最低限ルールを記述する必要があるため、テンプレートを使用しないルールを作成するよりも時間がかかることはあり得ません。初期コストが高くなることは覚悟してください (システム コードに直接ルールを記述するのではなく、変更する値を保存するためにデータベースを使用するシステムを構築する場合と同じです)。