今天讀了下ruby for rails也就是我們學說的r4r，感覺作者寫得比較細膩，同時透漏着作者無比的架構功能和程序設計水平。
關於系統的設計，作者談了三個任務，我覺得真實反應了我設計時的想法
（1）描述應用領域和建模。領域是你的應用的所在。領域可以是音樂店、大學、約會服務、地址簿或者硬件存貨等等。不管它是什麼，你都需要指出其中有些什麼——應用中存在什麼實體以及這些實體之間的關係。你對領域的描述將指導你的數據庫（你需要使用數據庫管理系統提供的管理工具來生成和初始化）設計，以及Rails應用的某些特殊部分的設計。
我覺得這點是一個項目成敗的關鍵，也充分體現了需求的設計。在數據庫中的表，可以說完全真實的反應了用戶客觀的需要，也就是完全會與現實世界的實物，它們的關係緊密的對應起來。所以，花費相當大的時間去分析客戶的需要和他所提供事物的內在準確關係是十分必要的。
（2）確定領域中可能發生的活動。領域模型是靜態的；它僅僅是事物。現在你要讓它成爲動態的。比如，向地址簿添加地址，從音樂店購買樂譜，用戶登錄一個約會服務，大學裏的學生註冊課程。要找出你的領域中的組成元素可以參與其中的所有可能的動作或場景。
我個人覺得這一步，如果一個人思維比較嚴密，還是比較容易想到的，關鍵是不是能把所有或者客戶都沒有考慮的東西想進來，這樣才顯得水平。數學出生的我，覺得自己這裏做得還行。呵呵
（3）選擇和設計領域中可以公開訪問的視圖。此時你可以開始從Web瀏覽器的角度來思考問題。一旦你確定你的領域中有學生，他們可以註冊課程，你就可以預想要有一個歡迎頁面、一個註冊頁面、以及一個確認頁面。買鞋子的客戶可以訪問款式選擇頁面、購物車頁面以及結賬頁面。每一個這樣的頁面或者視圖向用戶顯示，在領域的某個場景中的某個特定的點，事物是怎麼樣的。你必須確定存在哪些視圖。
最後一個任務就是程序數據流程的控制，這裏就要考慮一個人對於設計模式的功能和對算法以及數據結構的水平，同樣的人，可以是straightforward，清晰，健壯，可移植性高；也可能是horrible，亂得不行，儘管最後能實現功能，不過會給以後的維護帶來許多的困難。
