エンタープライズRails

「エンタープライズ Rails ―企業ユーザのためのWebアプリケーション設計術」を読んだ感想をメモ。
ラフなメモ書き。

【元ネタ】
DOAはRailsの銀の弾丸か - 書評:エンタープライズRails - ひがやすを blog

404 Blog Not Found:Rails使いでなくても有用 - 書評 - エンタープライズRails

RailsとかDOAとかCASCADEとか。 - Dis Communication - 符号無し

『エンタープライズRails』に学ぶ企業ユーザのためのRailsアーキテクチャ from Naoto Takai

「エンタープライズ Rails ―企業ユーザのためのWebアプリケーション設計術」はRailsのHowTo本と思っていたが、実際の中身はDOA。
Railsをスケールアップするには、DB設計やサーバーの配置のようなアーキテクチャをしっかり作りこまないといけないという主張。

当初はほんの少しのユーザがアクセスするだけしか想定しないRailsアプリ(例えばTwitter)が、あまりにも多くのユーザを引き寄せて、そのパフォーマンスやスケーラビリティを確保するのに随分苦労した話が最初に説明されている。
アーキテクチャを後付けで追加ないし変更していくのは非常に難しいのだ。

Railsだからアーキテクチャは不要ではなく、考慮して作ればいい。
何よりもRailsもRubyも表現力が高いから、DOAを使ってDBをしっかり作りこんでおけば、スケールアップがやりやすくなる。

「エンタープライズ Rails ―企業ユーザのためのWebアプリケーション設計術」のDB設計は正統派の部分もあれば、微妙にずれている所もあって面白い。
参照整合性制約を使うとか、トリガーを使ってビジネスルールをチェックするやり方は普通。

参照整合性制約を使う状況は例えば、商品マスタから商品を削除する場合、注文明細に該当の商品があれば削除できないチェックをDBMSで制御する場合がある。
そうすれば、注文情報の整合性をアプリケーションロジックに書く必要はない。

トリガーを使う状況は例えば、注文・注文明細にデータを登録した際に、注文履歴テーブルへそのデータを登録する時がある。
あるいは、合計金額のような導出属性をトリガーで自動計算させる方法もあるだろう。

マテリアライズドビュー(更新可能なビュー)を使うやり方は面白い。
とはいえ、Oracleならマテリアライズドビューを使うのは普通だろうが。

複合キーを使うために色々工夫しているけれど、ひがさんが話すように、サロゲートキーを使うのがいいと思う。
サロゲートキーの方がRESTful Webサービスと相性がいいからだ。

RailsやSeasarのような優れたWebフレームワークのおかげで、業務ロジックの実装が楽になっただけに、DB設計の重要性が逆に高まっている。
DB設計がしっかりしていれば、リリース後の本番運用で、スケールアップがやりやすくなるからだ。
つまり、Railsのおかげで、OOAよりもDOAに注目せざるをえない状況になってきていると思う。