Buriの敷居が高い訳を妄想。。。

Buriは敷居が高いといわれておりますが、何故敷居が高いかを妄想。

BPMとか何とか。

現場でコードを書いていると、BPM(Business Process Manegement)というものがなかなか身近に感じないのではないか、という事ですね。実は書いているコードそのものがビジネス・プロセスの断片であるのは間違いないのですが、ここでキモイのが目の前の画面はビジネス・プロセスの断片なのかどうか分かり辛いという点ではないか、と。

さらに、XPDLというキーワードｗ
僕も最初は惑わされたんですが、id:makotanも書いているようにBuri開発当初XPDLというフォーマットでプロセス・フローを書けるエディタがあったからXPDLになっただけで、BPELのエディタがあったらそっちで作ってたかも、という程度のものと考えれば良いらしいです。

どちらも無かったら、ExcelとかVisioで作ってかも知れない。

じゃなんでXPDL？というと、業務ロジックからビジネス・プロセスを見た時に、「状態」というものを捉えてSQLのResultSetを取ってくる事を前提にすることで、業務ロジックからその「状態」を特定する為のIF文が減らせるんではあるまいか？という作者の思惑と、「状態」という以上そもそもずっと同じではないのは当然なのですがその動線は必ず流れを作るのでそれをどう表記しようか、ということから、必然的にフローを書けるもの、となったんではないかと妄想。

「状態を管理する」って？

状態を管理する、というのがイメージし辛いというのもあるかも分かりません。

ここは完全に僕の妄想なのですが、業務システムで書かれるロジックは大抵が単調なLOOPとIF文でそれらはデータベース内のデータが「どんな状態か」を特定する為に書かれている、と。色々と条件を付けて「どんな状態か」を特定したら、そのデータを何かしら加工したりするのですが、その加工はだいたい「どんな状態だったから次はこの状態」といったものになるんじゃないか、と。

その状態の流れはXPDLで書けてBuriがそれをうまいことごにょごにょしてくれるので、状態を表すコードやフラグはデータモデルに要らなくなる、といった副産物まであるよ、といったところなんではないでしょうか。

IF文って状態を特定するもの？

一概には言えないのですが、id:makotanが言っていたIF文の種類「要件から生まれたIF」「設計から生まれたIF」「実装から生まれたIF」は基本的に状態を特定する為の条件付け的なIF文を指していて、「見せる為のIF」は含まれていないんだと思います。

要件から生まれたIFは、たとえると「○○の人が男性だったら××だけど、女性だったら▽▽として□□する」というもので、設計から生まれたIFとは、「なので、人は男性だったら○○だけど、女性だったら◇◇としよう」であり、実装から生まれたIFは、「だから人の情報を登録する際、男性だという人には"0"を、女性だという人には"1"を付けましょう」ということかな？

見せる為のIFとは、これらを踏まえて「"0"だったら"男"、"1"だったら"女"と表示する」というものなのでBuriのサポート外、っていうかプロセスを左右するようなIFじゃないのでどうでもいいよ、という事なんじゃないかなぁ。

ちなみに、例えとして性別を挙げたのはたぶん不適切で、本来は遷移するような状態の方が良かったのかも＞＜

いったんまとめ

という訳で、Buriの敷居が高いと言われるのは、今までのプログラムを作る際の視点ではなく、そのプログラムが一端を担っているプロセスを意識しないとBuriを使うメリットが無くなってしまう事に起因しているんだと現時点では推測してます。

いや、もちろんjaninoを使ってXPDL→コード→コンパイル→classファイル→Buriが使う、みたいな事を内部ではやっているようなので技術的にも結構敷居は高いとは思います。

ただしそれは本質ではなくて、こういった状態をBuriが管理してくれるようになると、今までIF文に使っていたデータベースの「XXステータス」みたいなカラムが不要になる、といった「今までの手法」とは違った視点でデータベースも業務ロジックも扱っていかなくてはいけなくなるので、結構大変というのが一番大きいのだと思います。

突っ込みモトム＞＜