これからはじめるRuby on Rails（2ページ目）

仮に、プロセスを中心にRailsアプリケーションを設計すると、どうなるのか。以下で検証してみましょう。

例えば、「商品を販売する」という機能を実現する場合、「販売する」という動詞に注目して、処理フローを設計します。しかし、サービス・レイヤーを定義しようと思っても、RailsではValidationがActiveRecordの責務となっているので、ついコントローラに処理を配置しがちです。

結果として、図1に示すような、再利用できないロジックになってしまいます。または、トランザクションを実行してしまう、複雑なコントローラになってしまいます。こういうケースが、非常に多いのが現実です。

解決策として、図2に示すように、販売を、名詞と見なしてテーブル・ビューと対応付けた上で、振る舞いを考えた方が良いでしょう。この場合、販売コントローラは、リクエストを処理して販売のインスタンスを作成するだけのシンプルな構成となります。販売処理の再利用も容易になります。

以上、従来の設計と、アクティブ・レコードのアンマッチについて説明しました。

それでは、Railsには、どのような設計が向いているのでしょうか。個人的には、ER（Entity Relationship）図に振る舞いを加えたようなものからスタートするのが良いのではないか、と考えています（最もRailsらしいのは、設計前に実装して反復しながら詰めていく方法です）。

なお、先述した、「処理の内容を顧客に説明するのが困難である」という問題は、「アプリケーションに期待する振る舞いを細かく定義する」という方向に進みつつあるようです。