業務ロジックとアプリケーションロジック

ってわけて僕は表現してます。ユーザグループを作った勢いで試そうとしているのが、jBPMとDroolsで業務の状態と業務ルールをアプリからとことん追い出そすとどうなるかやろうとしています。でも、Droolsルールでは英語というのは差し引いてもやっぱりDrools都合の記述って残ってしまうんですね。
で、webアプリで使っていくとなるとアプリ都合なことって結構あるんですね。手放しでお客さんに見せられない。そこでDrools流儀にのっとるとなるとDSLの登場ってなるのかなぁと。たまにシステム的な側面と業務仕様がまざっているドキュメントとかあったりするんですね、なんじゃこりゃと。こういうのもカイゼンできる一助になるのはとも思っています。やっぱ分けないと、ね。
あと仕様変更の際にもちょっと明確にいえそうな気もするんですよね、この業務ルールの変更だけなら作業発生ないので費用はかかりません、とか（データ構造、画面構成の変更は別途しかけが必要として）

みんなは業務ルールが変更になったらお金をもらってるんだろうなぁ。情シスの人達からさんざん「業務システムは作ってもらってからがスタートだ！その後の仕様変更/カスタマイズで費用が発生するのはビクビクする」という声を昔も今も聞いてるんです。なんとかしたいんですね、チャレンジングなことなのかもしれませんが。

今の時代はDroolsFlowというサブプロジェクトもあり状態も管理できます。Fusionというイベントセントリンックなこともできます。
そんなところも書いていけたらと思っています。Drools5入門記も始めたいと思っています。