1. 一個好的軟體架構，可以將修改的程式碼量，降到最低程度，理想狀況為0

1. 目標-使系統易於擴展，而不會因修改而產生較大的影響
2. 透過將系統劃分為元件，並將元件安排到依賴階層中而實現的，這類階層結構可以保護較高層級的元件，免受到低層級元件的變更所影響

2. 越上層的元件，擁有越核心的商業邏輯

1. 離I/O越遠的元件層級越高，離I/O越近的層級越
2. 越上層的元件，擁有越核心的商業邏輯
3. 用櫃檯小姐的故事來說明（參考連結1）
   想像一下你（user）今天走進一間公司(I/O)，負責接待你的，請你填寫資料的是櫃檯小姐(低層級-處理實作)，如果你是來談一筆大生意的，你會經過櫃檯，走到最裡面的落地窗辦公室，老闆正在那準備跟你討論（高層級-核心商業邏輯），我覺得這個說法滿容易想像和理解的，完整內容，請參考下方連結

3. 什麼是元件？

1. 大 [系統層級← 元件層級←模組層級←類別層級←程式碼層級 ] 小
2. 可單獨部署的單位，是系統在部屬的最小部分實體
3. 讀這篇的時候，我一直把元件和模組搞混，後續Ch12有針對元件做一個好像有說，又沒什麼用的定義，一切都是需要感覺，總之我自己認定的是，兩者差異在是否可以被獨立部署，或是說獨立啟動而不需要依賴其他模組，舉例來說像是微服務，我接受是元件，可獨立部署，且包含一個以上的模組

4. 如果元件Ａ應該被保護免於受到“元件B的改變”影響，那麼元件Ｂ應該依賴元件Ａ，Ａ←依賴←B，Ｂ中會 import A ，Ｂ知道Ａ，但Ａ不知道Ｂ

1. (Ｂ)低層級實作細節，應該依賴於(Ａ)高層級商業邏輯
2. 前台客服，替顧客服務的內容（實作細節），應該遵守老闆的的規定（商業邏輯）
3. 在這個部分，看懂書中p61頁的圖會滿有幫助的，其中有兩個重點，大板塊的是元件，箭頭的指向則是依賴關係，觀察依賴關係的時候，可以特別著重誰依賴誰，因此如果有變動，受影像的是哪一方，我認為本篇對我的學習重點是
   1. 學習使用 import 和看箭頭方向區分依賴關係，謹慎規劃不同模組或是類別間的依賴關係
   2. 理解 為何依賴方向，可以保護被依賴者，不受影響，資訊隱藏的好處

參考

1. 搞笑談軟工-Clean Architecture（4）：架構三原則首部曲—分層原則