最近看了Uncle Bob在Ruby Midwest 2011的演講（影片連結）介紹軟體架構。
Archetecture is about intent
一開始Uncle Bob列出幾種建築物的結構圖，藉此比喻好的架構設計能讓工程師迅速了解系統
從這裡再帶出web framework常採用的MVC架構
為何會有MVC的出現？ 為了讓系統耦合度降低 讓前端的設計不需要跟後端的資料庫或商業邏輯綁在一起
演講從一個user case講起，再畫一個UML圖解釋架構。
他使用類似MVC架構的系統(interactor, entity, boundary)來處理這個問題
例如： interactor負責application特有的商業邏輯，並且和entity有連結的關係，可以視為controller
entity則是處理資料庫存取，屬於一般application共有的行為
boundary把interactor產生的資訊秀出來給使用者，整體架構如下圖所示：
Uncle Bob解釋這種設計能將商業邏輯和使用者介面切開，二者之間少了相依性
而右半邊的interactor和entity可封裝成gem或dll(看是哪種application)
最左邊的delivery machanism負責將user input分配給boundary，可封裝成plug-in的型態，方便測試
What about MVC?
講到MVC這章，先從發明人Trygve Reenskaug開始介紹
延申到web application時會出現view和controller相依model的現象，如下圖
從測試的角度來看，view只要把資訊編排顯示正確即可，不需要關心後端的資料如何產生
對於商業邏輯的正確才是每次測試的重點，這點他比較偏好Model-View-Presenter
接下來Uncle Bob問觀眾做一次測試要多久？測了幾項？
4分半測1000多項 –> That’s good
1小時半 –> That’s bad >”<
對工程師來說，測試如果花太久的時間，之後每次修改都會猶豫要不要測試。
這也增加專案爆炸的機率…
Good Architeture
Uncle Bob最後提到早期一個wiki-like project。
從一開始他們就決定晚一點連結資料庫，先把application實作完
為了滅少測試時間，把wiki page存在memory中，雖然不能存檔，但至少能測試整個專案
後來他的同事實作FileSystemPage測試persistence，架構如下
而這時專案還沒有真正的database
A good architecture allows major decisions to be deferred
A good architecture maximizes the number of decisions not made
到最後客戶要求需要database，而他們只需要一天就把專案完成了
好的架構可推遲重大的決定；好的架構能滅少做決定的次數。