スライド
感想
どういう 話が聞けたというのは 英語だったこともあって＆雰囲気で理解した感じなので 聞きながら思ったことなどをツラツラと。
- Drools はルールエンジンで Ruleって「何をするか」ということ
- 大事なのは利用者と開発者のコミュニケーションロスを失くすこと
- Business and infrastructural code have very difficult life cycles
- jBPM こっちは「プロセス」を描く
- RuleとBPMを まとめて提供するのが Kogito
- Kogitoの読み方は「こじと」（こぎと ではない）
- （感想）ファンクショナルなアプリでいけるんだったら、ルールを書き換えて動的に反映するというのの価値ってどこくらい見いだせるのだろう？
- （感想）逆にみいだせるとしたらOpenJDKでしっかり動くアプリこそ強いのでは？
- とはいえ Kogito自体は Quarkus と SpringBoot を対象としたマイクロサービス向けなもので EEは対象外
- （感想）ルールエンジンを適用するとユースケース駆動になるから ビジネスルールのロジック部分は部品に出来るけどできるけど、データ部分は外に出ているからクラスではないんだよね。
- （感想）「判断」の見える化に止めるか ステートパターンの生成器としての役割まで担えるか？
懇親会で得られたプラスアルファ
- BPMの拡張がVS Codeにあるから、BPMを業務フローの整理として使うだけでも使えそう
- 少ない条件分岐だったらプログラムで実装した方が速いこともあるけど、大量の条件分岐を扱うのであれば 最適化が図られたDroolsに軍配ある*1
- ビジネスルールの見える化は表面的なルールエンジンの能力で、大量のパターンマッチングがルールエンジンの強み
- DroolsはGUIのフローでロジックを書くことも出来るし、Excelでも書ける。結局 それをDRL(Drools Rule Language)に変換してルールエンジンが実行する
- DRLから作られたエクセルへの可逆性は無いので、フローで作ったものをDRLに変換してからExcelのベースに使うというのは出来ない
- ルールエンジンの需要はあるとのこと（自分の周りでは聞かないけど、決して「懐かしい」ものではなくて十分現役）
- 機械学習（パターンマッチング）まで含めると、むしろ需要は 増える？
- 機械学習（画像解析）と違うので必要なのはCPU
さいごに
ルールエンジンには Excelで書いた設計からXMLを変換するツール作成に関わったこともあって その面白さというか 業務の見える化みたいなところは興味深いと改めて思った。所謂 自動生成的なところがあるので かつてあれこれ考えたように*2、その付き合い方みたいなところの落としどころに検討の余地ありとは思っているけれど。とはいえ、今 自分手元にある開発資産は マスタメンテレベルのCRUD的なものなので DDDとかの文脈に出てくる「ドメイン知識」的な要素はないんですよね。何かしらの業務アプリ的なもののOSSを自分の思ったようにリプレイスしたりしながら アレコレやっていくと 何か良さげな整理が出来るかもしれないとは思いつつ、他に作りたいものとかあったりで 結局 後回しにしてしまうんだろうな。。
