ratio - rational - irrational

ここまで、RailsでABDもどきをやってきたところから、ABD (Activity Based Modeling) の体系を想像する(1)の「謎と課題」に回答してみる。

resource の中に Relationship(外部キー)が混在していることのおかしさ

おかしくはない。はぶさん曰くIREを前提に考える方がよりRDBの背景理論の素朴な実装ではあるらしいけれども、素朴な実装でIREが沢山発生してしまうことによる結合コストを減らすための最適化テクニックとして混在させるというのはそう変な話じゃないのだと思う。

ただ、損得で考えればあとで書いてらっしゃる「各業務専用のデータアクセス」がやりづらくなるし、それで私は原点回帰にしてeXtremeなABDは面白いと思ってる。

業務ごとにオブジェクトのチェーンを手繰りまくる必要

なんか、書いてみるとSQLで済んじゃうんだよね。だからオブジェクトを手繰る必要は減る。

SQLを徹底排除する方式とは相性が悪いかもしれない。Table = クラスを素朴に実装してSQLを排除しようとしている種類のORM実装ではIREが入る分、クラスも増えるし、こういうのとは相性が良くない。

SQLの直接記述を視野に入れたS2DaoやActiveRecordの場合はSQLを発行して、それで1つのロジックが処理できてしまう。いや、これはあくまでもObject-Relationalインピーダンスミスマッチの問題であって、データモデリングに直結する話では無いのだけれども、経験から、ABDだと素人にもこういう手法がやり易い気がする、というだけの話。

各業務専用のデータアクセスがかえって簡単になってしまう

まったくもってその通り。重宝してます。

排除しなくてよい外部キー

悩んでます。試行錯誤中。