ぶり祭り2008
先日ぶり祭り2008に参加してきました。どんな祭りだったかは ぶり祭 2008 - 豆無日記 が詳しいのでそちらで。しばらくBuriを調べてて、「これでワークフローエンジンとして耐えられるんだろうか？」と疑問に思っていたんだけれど、その疑問は解決？した。
ぶりはワークフローエンジンじゃない
そもそもワークフローエンジンじゃないんだから、その上でワークフローを組み立てるのが間違ってるよっていう話*1。だからスタロジ以外の人間が知らずにぶりに手を出すとハマるよ、と。で、じゃあぶりは何なのか？っていうと「エンティティステートマネージャー」ですよと。ここ重要です。
では具体的にぶりはどう料理したら美味しくいただけるのか。
- エンティティとはS2Daoで言うところのEntityと同じレベルで、昔ITを使う前に人間が手で書いていた伝票のことをイメージすればよい。XPDLのフローを流れるものなのでXPDL上には登場しない。
- ステートとはそのまま「状態」のこと。「申請中」とか「承認済み」っていうのがステートになる。XPDLではアクティビティ（箱）。
- 「申請する」とか「承認する」というアクションは次のステートへの遷移（トランジション）になる。XPDLでは遷移。
- ぶりのフローは、伝票ごとに１つ。申請書は申請フロー、発注書は発注フローを回る。１つのXPDLに業務フロー全体を書いてはいけない。
こうして見てみると、XPDLじゃなくてステートマシン図を書く感じがしてきた。*2
自分の中にあった「ワークフローとは」的な考えは、「申請」「承認」っていうのが箱で、それぞれの箱で伝票に対しての作業が終わったときに次の箱に遷移する、っていうものだった。だからぶりは使いづらいと感じてんだけど、使い方が間違っていたんだと納得。ぶりを使うときにはワークフロー的発想をどっかに追いやって、単に伝票の状態管理なんだって捉えて、業務フローをステートマシン図に落とし込むことを心がけよう。
ぶりを使う上で、実装段階で重要なのは「スタロジでは一回もBaoを使ったこと無い」ってこと。状態を進めるのはtoNextStatusで、状態の取得はBao経由ではなくSQLでとっちゃう。Bao経由しなくていいんだ、っていうのは収穫。ちょうどDBFluteもS2Dao依存を弱めてきているし、パフォーマンス考えてもBao経由は無いと思ってたので良かった。*3後はBuriの内部テーブルの構造を都合のいいように変えられればいいかな。
後半はギョイゾーの紹介。ギョイゾーとぶり☆すたについては、みんな絶賛するんじゃないですかね。要件定義してたらFlashの画面ができてもう動きますとか、さらに安いですってきたら、発注側としたら絶対興味持つと思う。残念ながら自分は発注側の人間ではなく、中小規模案件を対象に仕事をしているので、正直感動してる余裕なんてなかったですけど。。
