データモデル自体はアジャイルなのだが...
全体に与える影響が極めて大きく、後戻りしにくい「スポンジ層」というのが存在する。そのひとつが渡辺さんの言われているデータモデルである。
平鍋さんが「(業務システムの)データモデルの変更コストは非常に高い」という意味のことを書かれている。これについて。
データモデル自体の変更コストは非常に低く、後戻りし放題である。新しいスキーマでcreate tableして、データをロードして、drop table/rename tableするだけだからな。
しかし、データモデルに手を入れるためには、同時に既存アプリケーションへの影響を調査して、漏れなく修正しなければならない。
プロジェクトが進行するほど、データモデル改変の影響範囲は広がり、修正点も増えていくだろう(元記事でデータモデルを「高リスク制約」つまり「プロジェクト開始からの時間が経過するほど変更コストが高まるもの」に分類しているのは、このことを指しているはずだ)。
この手間をデータモデルの変更コストとしてカウントすれば、元記事にあるように「データモデルの変更コストは高い」という結論になる。
私のようなデータベース中心主義者から見れば、データモデルは非常に俊敏なシステムの構成要素であって、それを参照するアプリケーションこそがアジャイルではない、ということになる。
問題はデータモデルではなくアプリケーションなのだから、
といったことでは、元記事で言う「データモデルの変更コスト」は下がらない。
代わりに
- データモデル変更の影響範囲を極力狭めるようアプリケーションをレイヤリングする
ことが重要(というか、不十分なんだけどそれぐらいしか打ち手がない)、と考える。
現状、「データモデルをアプリケーションに極力漏らさないようにする」ことが当たり前になっているとは思えない。
例えば、割とメジャーなO/Rマッパーが持つ「クラスをそのまま基底テーブルにする」という発想。JPAの @Table みたいな考え方。
これ使ってしまうと「社員と部門の関係を1:NからM:Nに変更」といったデータモデルの変更が、アプリケーションの各レイヤに筒抜けになる。
もちろん「社員マスタにマップされた Employee クラスのインスタンスはDAO層でのみ参照する。より上位の層には Employee のデータを転記したDTOを参照させる」とかすれば既存アプリ内の影響範囲を限定できるが、やらないでしょう。
あるいは「スキーマレスなDBは、仕様変更があってもいちいちスキーマを変更しなくてよいので、外部環境の変化に強い」みたいな話。
スキーマの変更自体は、参照元アプリケーションの調査・変更に比べれば大した作業ではない。スキーマの変更コストをゼロにしたところで、アプリケーションの変更量が変わらないか、逆に増大するならば意味はない。
ところが、スキーマレスDBを採用したら「社員と部門の関係はM:Nである」といったデータ間の関係(=要するにデータモデル)はプログラムで表現するしかなくなる。つまりデータモデルがアプリケーション全体の中に溶け込んで拡散する。よって論理的なデータモデルの変更が、即アプリケーション全体の調査・修正につながってしまう。
元記事で言う「データモデルの変更コスト」を下げるためには、アプリケーションの中でデータモデルを参照する範囲をぎりぎりまで絞り込まなくてはならない。
RDBを前提にすれば、「データアクセス層を作ってその中だけでSQLを発行する。データアクセス層から出てくるものはデータモデルを反映しない、単なる二次元の結果表にすればよい」ということで、そんなの当然じゃないかと思われた方はおめでとうございます。他にも打てる手があるという方は教えてください。
