ABD飲み会参加
Railsな人々、Seasarな人々に挟まれて、無所属系で人見知りの僕は大変緊張いたしました。
ちょっと面白かったのは飲み会前の妙に緊張した雰囲気。全員が沈黙して資料読んでる風景がすごかった。店員がちょっとびっくりしてたね。
僕は、宴会初期はid:habuakihiroさんの隣の位置という好ポジションにつけながら、なぜかABDの話をほとんどしてなかったり。(だめじゃん)
ちょっと話していたのはUIの話。ちょっと話題になったのは、例えばMSOfficeのようなGUIアプリのデザイナはどんな仕事をしているんだろうという話。なんとなくオフィスアプリの「デザイナ」がHTML相当の画面系のコード(WPFみたいな)に触ることが無いような気がする。今のWeb系プログラマの常識がどこまで常識なのか? あとWindowsPowerShellカッコイイという話。
そのあと他の人とABDやワークフローの話などなど、、2次会まで。
個人的なABDの理解としては以下のとおり。(後半OO用語になってます。すまんす)
- ABDではResourceはもちろんEventも、他のエンティティへのリレーションシップを(原則)持たない
- T字形みたいに対照表(Event)とか対応表でエンティティ同士を結ぶためのギミックを考えるのはモデリング初心者には大変。
- そのかわり画面1種類につき、一種類のActivityを対応づける。 こいつがそのタイミングで必要なエンティティ間のリレーションシップをすべて管理。
- OO厨的にはActivityは多項関連クラス。こいつのインスタンスは参加するエンティティ(のインスタンス)間のリンクと対応する
- あと、Entity間の多重度のようなビジネスルールがERモデルから消えてしまう(DISられるポイントの一つ)
いくつか犠牲を払いつつも上記のメリットは以下の点にあると思う。
- 「画面」をしっかり考えることができれば、それに対応するActivityがピシッと決まる。
- Activityに紐つくEntity(イベントやリソース)は画面の項目から明らかである。多重度もここで決まる。
つまり画面が決まれば、それに関係する部分のモデリングが終わっている状態になる。
『モデリングする』…そんな言葉は使う必要がねーんだ。なぜならオレやオレたちの仲間は、その言葉を頭の中に思い浮かべた時には！実際に相手を殺っちまってもうすでに終わってるからだ！だから使った事がねェーッ！『モデリングした』なら使ってもいいッ！」
画面をまたがって仕事の状態を追跡する場合に問題点が残る。そういうのは画面には明示的に現れないから。で、そこらへんはS2Buriを使ってなんとかするというのが主旨。ワークステートはDBでは管理しない。以上。(と理解しました)
これが万人に合うかどうかは別問題。ある程度モデリングできる人ならばERDレッスンで十分であるという話も。
あと、いわゆるOO厨メソッド*1ならば、
- AggregateRoot役のクラスを定義する。[受注プロセス]クラスとか。
- AggregateRootがステートマシーンの役目を果たす
- そのステートマシーンの遷移情報はDSLっぽいので記述。Javaならアノテーションかな。
- いろんなEntity(イベントやリソース)はコイツにぶら下がる形になる*2
みたいな感じになるのでは。Railsだと↓こういうのがある。id:t-wadaさん情報
http://lunchroom.lunchboxsoftware.com/articles/2006/01/21/acts-as-state-machine
S2Buriの集中管理ではなく、分散管理になる感じ。このやり方がいいか悪いかは全くよくわからない。メリットは単体テストしやすい(気がする)点。あと、複雑な状態マシン*3を扱いやすい点かな。
あと最速配信研究会の中の人が、あんなに熱くて若い人だとは思わなかった。かっこいい!
