Layering 是軟體設計師最常用的技巧，可以將複雜的軟體系統打散。上層依賴下層，下層不知道上層。最好的例子就是我們的網路 OSI 七層架構了(現在通常簡化為四層了)。
Layering 的好處很多，你可以只知道一層不用知道全部、可以替換任一層、容易標準化、上層可以有各種選擇等(例子想OSI吧)。缺點是可能會帶來 cascading changes (因為每層layer包了某些東西，但是又沒有全部都包的好好的)，你如果要在UI多一個欄位，嗯，那個欄位也要在database，嗯，每一層都要加上那個欄位的處理… XD。另一個缺點就是多餘的Layer會降低整體效能，但往好處想，某一層做好最佳化，上面的都會受益。
困難的地方在於各層要有什麼以及每一層應該要有的責任。
本書使用 Three Principal Layers 來討論 : Presentation, Domain (Logic), and Data Source 。你應該可以想到大概是怎樣了，我就不寫了 :p
幾個重點像是 domain 跟 data source 不應依賴 presentation，保持替換 Presentation 的空間。而 domain 和 data source 之間的關係則要看你用的 architectural patterns 了。
一個困難點決定哪些 logic 在 domain，因為我們常把 domain logic 放到 presentation 去。作者提了一個簡單的測試方法，請你想像另一種很不同的 layer 情況，如把 web interface 換成 command-line ，看看是不是有功能重複了，如果有就應該搬到 domain logic 去。
本章最後談選擇 你要在哪裡跑你的 layer。通通跑在 server 是最簡單的作法(如用web browser當client)，因為容易升級跟補釘囉。看起來都跑 server 就好啦，但是為了 responsiveness 回應速度 或 disconnected 離線使用 這兩個原因，你也許得跑東西在 client 上。
本書假設 data source 都在server跑，因為若是要跑離線的情況，就得處裡 client 跟 server 同步的情況，嗯，作者說這不在本書範圍 :p 後記: 你可以找找 Data Patterns 的資源
presentation 如何? 這要看你的 user interface 類型了，跑視窗顯然你得放在 client，跑web就是放server囉(有個例外是X servers in Unix)。
domain logic 放 server 容易維護，而會放 client 的理由就是為了回應速度跟離線。兩邊都放一點顯然會變複雜，盡量不要醬子。