※ 引述《DongFeng ()》之銘言：
:
: 目前手上的 Project 使用 Laravel Framework 開發, 程式碼架構依目錄區分為 Controller(Presentation)->Service(Business)->Repository(Data)->Entity
:
: 基本上各層的存取範圍以箭頭方向為準且不可逆, 但因為協同開發的關係偶爾還是會出現 Controller直接存取Repository的情況
:
有興趣可以參考 Uncle Bob 的 Clean Architecture，YouTube 上有演講錄影，
也有出書，網路上也可以找到實際的程式碼。但因為是概念性的東西，每個人的
理解和實作都有些不同。
我覺得他有一個好處，是可以跳脫 Framework 的思維，單純回歸到最原始的 OOD
的概念。這也是為什麼每個語言 / Framework 都可以實作 Clean Artitecture，
但每個人做得出來的東西又都長得不太一樣的原因。
:
:
: 因為沒有新的 feature/issue 的關係, 所以本週有空檔可以回頭整理之前寫的程式碼
:
: 越整理我就越沮喪
:
: 我發現自己沒有分辨哪些邏輯該歸類到哪一層的能力, 舉例來說:
:
說真的，我自己是覺得很多時候都是 trade-off，但如果真的很在意，其實這個
架構提供了一個滿不錯的指引，但即使有這份指引，還是要考量很多東西。沒有
最好的架構，只有最適合當下情境的架構。
這篇文章我會試著以我的思路，提出一些問題，再提供一些假想的情境，然後說
明如果是我，我會怎麼安排。
Clean Architecture 把系統畫分成以下幾個組件，而且各自的職責非常清楚：
1. 與核心業務邏輯相關的，抽象的組件，這些組件不應該知道任何的實作細
節，例如資料庫，Controller 等等。
- Entity
- UseCase 物件
2. 讓實作細節與核心業務邏輯溝通用的介面，通常又分兩類：
- 從某處拉資料，例如 Repository 介面
- 把資料送到某處，例如 Presenter 轉換成讓 Controller 往外吐的 JSON
3. 實作上述介面的類別，也就是實作細節
: