在我們開始之前，我們再次回到The Clean Architecture的這個概述圖上來。上篇文章筆者論述了The Clean Architecture整潔架構的基本理念，分層及黃金法則。
這一層為『實體』層，它應該是你系統業務的核心所在。
我們都知道，任何一個系統，最終本質上都是業務的支撐與反應。比如一個銀行交易系統，一定是先有銀行交易的業務，再有系統，系統的形式也可以多樣化，如WEB端，手機端，ATM機等。
如果基於這個場景來分析，那交易本身相關的業務邏輯，就應該放在Entities層，如轉帳，存錢，取錢等，這些屬於業務核心。你應該把這些業務的邏輯放在Entities這一層來實現。
業務是與系統無關的，一個業務一定可以有不同的系統承載形式，比如WEB，移動，桌面客戶端，或類似ATM等智能設備等
2.2 Use Cases這一層為『用例』層，也就是你的系統的每一個用例在這一層都應當有對應的反應或映射。
需要明確它與Entites層的區別，很多人會搞混這兩層的差別。
最大的一個差別在於：
Entites關注的是核心業務，不關注系統用例
Use Cases更關注系統有哪些需求，它並不實現核心業務，它是調用核心業務來滿足用例上的需求。
再換言之，同一個業務，如銀行業務，它的核心業務層，也就是Entites應該是同一個，與具體的系統無關，不管你的系統是WEB承載，還是使用手機承載，或是ATM機來承載，它們應該共享同一個Entities層
但Use Cases層則不一樣，因為不同的系統，用例不盡相同，一個銀行業務的WEB端與ATM端，其功能與輸入輸出都存在較大的差別，所以它們的Use Cases層是不一樣，不同系統有自己的這一層。
這一層有個非常明顯的特徵，就是它應該非常薄，業務應該是由Entites來實現的。這一層還包含一些非業務的行為，如日誌，緩存，事務，分頁等，這些大多是系統級的需求，我們通常會把這些放在這一層來實現2.3 Interface Adapters這一層其實是與UI關聯比較緊密的，如果你是WEB，那這一層大多可能是MVC所在。如果你是WEB並且用的是Spring，那這一層就是Controller。如果你在移動端，那這一層就是ViewController或Activity。2.4 Frameworks and Drivers.比如你的資料庫是MYSQL，你是使用JPA或Mybatis來與資料庫打交道。再如，你使用了緩存，可能使用了Redis或EHCache來實現你的緩存。記住一個重要原則：實現細節是應該推遲到最後再考慮的當然，很多人會搞不清楚究竟怎麼樣才能把實現細節放到最後果來考慮，很多人可能從來沒有寫過類似的代碼，不清楚該如何實現。因為他們在思維上，討論一個業務時，會自然而然的想到資料庫，很難想像或理解如何做到先關注業務，後關注數據實現3 區分業務與系統需求在實際業務分析過程中，我們很容易將業務與系統需求混淆，很難分的清這兩者。很多系統都會存在一個需求，記錄用例操作日誌，比如XX時間，XX做了什麼操作。大多數情況下，這是一個系統需求，因為本身大多數業務不存在這個行為，這是一個典型的因為系統帶來的行為的需求。因此，這一個邏輯大多數情況下你應該放在Use Cases層。但如果是類似銀行等系統，記錄用戶行為，如張三在10月1日09:10分存了1萬元錢這種並非系統帶來的，而是業務本身就一定需要記錄的，那這個需求應該放在Entities層來實現。所以，分析具體的需求是業務行為還是系統行為是非常重要的一件事。它決定的這一塊的邏輯放哪一層來實現。4 如何實現整潔架構與具體的技術無關，筆者在論述分層的過程中，未與任意具體的技術框架相關聯整潔架構與技術方向無關，這些原則適應於任何方向，包含後端，移動，WEB，甚至是ATM等類似設備的系統很多人會問，如何實現這樣的整潔架構,很多開發人員從未使用過或考慮過類似的架構，也沒有類似的經歷。其實，從筆者自己在各個技術方向的實踐經驗來看，基本上所有的面向對象語言都是非常容易做到上述的架構的實現。接下來，筆者會著重論述面向對象的基本原則，只要你能理解面向對象的基本原則，就會很輕鬆的理解如何實現整潔架構