DOAはRailsの銀の弾丸か - 書評:エンタープライズRails

Railsは、最初に素早く動くもの(scaffoldなど)を作って、そこからフィードバックをもらい、少しずつ動く状態を保ちながら、改良していくスタイルです。
スモールスタートを切るには最も向いているスタイルです。しかし、最初はそれで良かったものの、プロジェクトへの要求が増えるにしたがって、コードは複雑になっていき、だんだんメンテするのが大変になってきます。
これはRailsの問題ではなく、システムのアーキテクチャの問題です。

システムでやらなければならないことがたくさん増えたときでも、急にコードが複雑になることなく、きちんとメンテナンスし続ける方法があるなら、誰でも学んでみたいと思うでしょう。
その方法を教えてくれるのが、エンタープライズRailsなのです。

エンタープライズ Rails ―企業ユーザのためのWebアプリケーション設計術

この本は、DOA(Data Oriented Approach)の本です。ビジネスをデータモデルできちんとあらわすことこそ、DOAの本質であり、長くシステムを使い続けていくためには必要なことなのです。

RailsはActiveRecordを使うことで、あまりRDBMSを意識しなくても使うことができます。しかし、Railsで開発するときに、本当にこのようなモデルでいいのか不安になったことはないでしょうか。
OOA(Object Oriented Approach)の世界では、モデリングの理論は、確立されたものがありません。DDDとかRUPとかあるけど、結局「イテレーションやユーザと対話しながら、実際に作って試さないとわかんないよ」という話なので、かなりの試行錯誤が必要なわけです。もちろん、過去にうまくいったパターンというのも蓄積されつつはありますが。
それに対し、DOAの世界では、モデリングの理論が確立されています。そういう既に確立された「巨人の肩にのる」ことが、モデリングで成功する確率を高めるのです。

Railsでは幸いなことに、DOAでモデリングした結果をそのままActiveRecordのモデルにマッピングできます。自信を持ってモデリングできるようになるためにも、本書で、DOAのモデリング手法を学ぶことをお勧めします。

ただ、1つ注意点があります。本書の中で、複合主キーはすばらしいもので、それをRailsで何とか使うようにする方法が説明されていますが、無理やり感があるので、Railsではidを使うほうが無難だと思います。
DOA屋さんは、複合主キーが好きなんですよ。データモデルとしては素直な表現だから。でも、フレームワーク(Rails)と相性が悪いなら無理に使う必要はありません。

本書は、Railsを使ってDOAのやり方を説明していますが、それは、他の言語でもそのまま役立ちます。アーキテクトになりたいなら、他の言語を使っている方も読むことをお勧めします。

ドメインモデルってあるじゃないですか。ドメインモデルとデータモデルを別個に作ってそれをDataMapperで結びつけるのは、設計も大変だし、インピーダンスミスマッチも発生するから、止めたほうがいいって昔から何度も言っているんだけど、必ずドメインモデル命の人がやってきて、議論がかみ合わないまま平行線になるんですよ。
ERモデルとドメインモデル - yvsu pron. yas
ドメインモデル - yvsu pron. yas
続ドメインモデル - yvsu pron. yas

この中でも書いてますが、モデリングは理論的に確立されているDOAでおこなって、ドメインモデルは、それとほとんど一対一にマッピングする方法が、今のところ成功する確率が高い方法なんじゃないかと思っています。別に押し付ける気はありませんが、私の一押しです。