RailsとABDとCRUDとワークフロー

羽生さんのABD(Activity Based Datamodel)ですが、それを知った感想を自分なりにすごく乱暴にまとめると、DBをイベント系とリソース系にわけた上で、仕事っていうのはリソース間やイベントとリソースの間になんらかの関係を発生させる捉える、という考え方かなぁ、と。

イベントとリソース

売上げが立つ、というイベントはつまりお客さん(リソース)と商品(リソース)との間に購入/入金という関連が発生するというふうに捉えられます、と。
あんまり例えが良くありませんが、ビジネス上のできごと＝イベントに着目し、イベントも関連テーブルのエンティティを素直にcreateすることで表現するという方法論だと読んでいます。

さらにDBを設計するということは、そういったイベント、すなわちビジネス上のアクティビティをどう記録するか、という観点でデータの持ちかたを設計していくということなんじゃないでしょうか。

イベントをCRUDする

このへんまで来ると、先週のRuby会議でのDavidのプレゼンを効いた人はピンとくるかもしれません。
Davidは「MemberがGroupから抜けるのはMembershipがdropされるのだ」と言ってました。「AccountがPlanを採用/購入するのはSubscriptionがcreateされるのだ」と言ってました。それって~~Plag~~ABDというか、イベント系を関連テーブルとして切り出すという考えとベストマッチしません?

幸い、現在のRailsにはhas_many :throughと言う書き方で関連テーブルも処理対象のオブジェクトとして記述する方法があります。AccountとPlagの間に横たわるSubscriptionをも簡単にCRUDできるのです。というかそういったイベント/関連をCRUDするというのが業務を進めるということなんじゃないですかね？ Davidもたぶんそういってるし。

そしてワークフローへ

仕事というのは、対象ドメインのコアとなる(データ|帳票|イベント)にさまざまなイベントが発生し、完了していくことで進んでいきます。上記の文脈で言えば、コアイベントに関連したイベントやリソースとの関連をCRUDしていくのが仕事の流れだといえます。

するとどうなるか。ABDでイベントを切り出したDB構造であれば、そのコアイベントに対して次に行われるべき仕事はDBをみればわかります。正確に言えばイベントの進捗状況と、その進捗状況において次に実行される仕事の対照表があれば、次はどんな仕事がなされるべきかがわかります。

繰り返しますが、ここで言う"仕事"は関連/イベントのCRUDです。ある仕事を終えたコアイベントが次に行われるべき仕事を定めるのが業務フローです。業務フロー中が変わることは合っても一つの仕事で付与されるイベントの結果や関連はなかなかかわりませんよね？
(eg.稟議でも年休申請でもいいですが、上司の承認が行われるまでの回送フローは変わっても、「上司が承認する」ことはなかなか変わりません。この場合、承認が仕事、回送フローが業務フローですね。)

であれば、業務フローの記述と仕事の記述はプログラム的にも別の概念のもと変更に備える必要があります。この業務フローを簡潔に定義して、それぞれの仕事の場面で対象となるコアイベントをフレームワーク側で用意できたら素敵じゃないですか？　当然、業務フローが変わる場合は、設定ファイル(たとえばconfig/workflow.rbとか)を書き換えて、それぞれの仕事(=action)への変更は無しで。

RailsにはいまのところBuriはない

で、不勉強のためにこういう捉えかたでよいのかどうかは不明ですが、ABDを知ることによってワークフローエンジンの有効性というものに遅蒔ながら到達できたわけです。
そうすると羽生さんがワークフロー/ワークステートエンジンであるBuriを評価している理由がなんとなく分かってきた気になれます*1。

最初のRailsの生産性の話に戻ると、いまのところRailsではこのようなワークフローを実現するためのエンジンはありません。これは書けるか書けないか、というよりも、いまそこにあるかどうか、という問題です。残念ながらRailsにはまだないんですね、ワークフローエンジンは。

そこはマジカ&Buriなソリューションに及ばないところではあると思います。

2006/06/19 22:19

誤字誤変換を修正。

*1:このへん誤読していたら恥ずかしいなぁ。。。