そーだいなるらくがき帳

そーだいが自由気侭に更新します。

DBリファクタリングの勘所と所感

表題についてそーだいなる見解を書き残します。
今年の夏に id:koemu さんにbuilderconの懇親会で下記のような話をいただいていました。

懇親会で、DB側ばかりでなくプログラム側でも適切なドメインモデルの設計ができていれば、リファクタリング時の影響範囲がさらに小さくできるのでは?という話をしたところ、この辺りはアンサーブログを書いてくれるかもしれないってことなので期待しています!!!

www.koemu.com

忘れてないんですよ!しっかり覚えています。

結論

仰る通りだと思うし、適切なドメインモデルはRDBに限らずデータストア層のリファクタリングの負担を大きく減らすと思います。





ここから先は僕なりの考え方を書きます。 実は似たような話を PHPの現場 っていうポッドキャストでも触れています。

php-genba.shin1x1.com

システムの柔軟性

勿論、コードの綺麗さやアーキテクチャのシンプルさ、そして実行速度などはとても大切です。 でも同じくらいシステムの柔軟性も大切です。 ここのバランスがシステムの柔軟性を担保してくれている遊びの部分だと思っています。 例えばコードのどこが変更可能なパーツでアーキテクチャのどこが差し替えやすいミドルウェアなのかっていうのを意識して設計しておくとリファクタリングの影響範囲を小さくできます。

アプリケーションはデータベースよりも変化に強い

データベースよりアプリケーションのほうが絶対的に変化に強いです。 テストコードも書きやすいし、振る舞いのテストもしやすいし、振る舞いの変更もしやすいしです。 そしてデプロイもデータベースに比べて簡単です。 データベースだとデプロイするときに、ロックのことを考えなきゃいけないですし、マスター・スレーブのデータの整合性を考えないといけません。 例えば同じことが、トリガーやストアドとアプリケーションで出来ることが同じ場合、なぜアプリケーションが良いかというと圧倒的に元に戻しやすいし、変更しやすいからです。 だからこそシステムの柔軟性を意識する際にRDBとアプリケーション側の責任分界点を意識することが大切です。

ビジネスロジックはデータベースに持たせないほうがいい

これはSoftware Designの連載中のRDBアンチパターンでも度々テーマに出しました。 なぜならばビジネスロジックは度々変更されるからです。 そのため前項の アプリケーションはデータベースよりも変化に強い でも触れた通り、データベースにビジネスロジックを持たせることは悪手です。 だからこそRDB側には事実のみを保存することを意識することが大切です。 ただしアプリケーション側でデータを守ろうとすると、バグとヒューマンエラーにめちゃくちゃ弱いです。 そこで変わってしまっては困る データの事実RDBMSの制約の機能で守るのです。 ここがアプリケーションとRDB責任分界点です。

スコープを小さくする

事実をRDBに保存しましょう、アプリケーションにビジネスロジックを持たせましょう。 特段変わったことではなく一般的なことです。 この前提の延長にスコープを小さくしましょう、というのが来ます。 そこでRDBなら正規化だと思うし、アプリケーション側ではドメインモデルを整理しましょうとなると思っています。 正規化をすると追加が楽になるし、ドメインモデルを整理するとパーツの付け替えが楽になります。 いい例がリポジトリパターンだと思います。 ビジネスロジックからすればUserオブジェクトの元がRDBMSだろうがfilesystemだろうがキャッシュから取り出していうようが知らなくていいことですよね。 そこを抽象化して取り出したモノがオブジェクトなわけで、そのためにリポジトリパターンでオブジェクトだけを返したりするわけですよね。 こうすることでアプリケーション側からすると実際のデータストア層を意識する必要は無くなるわけです。 データストア層を意識しないということはRDB側の変更も意識しなくていいですし、振る舞いさえ同じに出来ればアプリケーション側を気にすること無くRDBリファクタリング出来るわけです。 だからアプリケーション側もRDBMS側も意識するスコープを小さくすることが大切だと思います。

じゃあどうやってそこに行くか

結論リファクタリングしか無いと思うのだけど順番で言えばアプリケーションが先だと思っています。 なぜならば同じようにリファクタリングもアプリケーションの方がハードルが低いからです。 そしてアプリケーション側がRDB側に依存してる場合にRDBリファクタリングに行って、またアプリケーション側に戻ってきての繰り返しです。 ここは一朝一夕では完成せず、しかも本来のアプリケーションの追加実装もありますから強い意志が必要になる部分です。 だけどここを正しく改善していくことはサービスの寿命に直結するところですので頑張って行く価値があります。




id:koemu さんへの回答になってるかはわからないけど僕からの回答です。