私は、DRY 原則 (Don't Repeat Yourself) に問題があり、Rete ルール エンジンを中心に展開する依存関係を最小限に抑えています。
大規模な IT 組織のルール エンジンはエンタープライズになる傾向があります (大文字の「E」に注意してください。これは深刻なビジネスです)。すべてのルールは一度だけ表現され、ナイスで DRY であり、高価なルール エンジンに集中化される必要があります。グループはルール エンジンを維持し、ルール セットの管理者です。
その IT 組織がアメリカの保険会社の一部である場合、多くの規則が存在する傾向があります。すべての州と製品に適用される規則がありますが、各州は製品ごとに独自の法律を展開する傾向があるため、規則はこれらの癖を反映する必要があります。カテゴリは多数あります: 保険数理、保険引受、さらには第三者機関からの信用および自動車のレポートの注文などです。
設計の観点から私が抱えている問題は、ルールと処理を集中化することは確かに素晴らしく DRY ですが、コストがかかることです。
- 中央に配置されたルール サービスにアクセスして結果を返すための追加のネットワーク ホップ。
- ルール エンジンが SOAP Web サービスとして公開されている場合はさらに複雑になります。消費者は SOAP 要求をパッケージ化し、応答を OXM して自分のドメインに戻す必要があります。
- ルール エンジンを維持する企業グループ、ルールを設定および維持するビジネス、ルールを使用する開発者の間の追加のインターフェイス。
- 追加の複雑さ - データ駆動型のソリューションで十分な場合があります。
- 追加の依存関係 - 独自のルールを制御できないコンポーネントは、テスト、展開、リリースなどのために、ルール エンジンの外部依存関係について心配する必要があります。
これらの問題は、他の多くのエンタープライズ テクノロジ (B2B ゲートウェイ、ESB など) で発生します。
同じエンタープライズ グループも、SOA を基本原則として宣伝しています。しかし、適切なサービス設計についての私の理解では、それらはビジネス スペースを並べて表示し、冪等、独立、および分離する必要があります。ルールが別の場所で維持されている場合、サービスはどのように独立して分離されているのでしょうか?
ルールが孤立した状況でのみ適用されることを示すことができる場合、依存関係を排除することは集中化よりも優先されるべきであると主張して、私は単純さの側で誤りを犯したいと思います. 議論がその日に勝つかどうかはわかりません。
だから私の質問は:
- 中央集権化と独立性の議論のどこに当てはまりますか?
- ルール エンジンなどのエンタープライズ ツールの使用経験は?
- どうすれば孤立の主張をより強くすることができますか?
- 私の見解が間違っているとすれば、中央集権化を支持する理由は何ですか?