Clean Architecture的目的之一，是通過一種清晰的方式，把應用的業務邏輯封裝起來。
上圖展示了該架構，其中領域實體（Entity）和用例（Use case）處於“洋蔥”的中心。
Uncle Bob:
用一組同心圓表示不同層級的軟件代碼，總的來說，越往內，抽象層次越高。最外層的圈代表的是機制級別的系統。最內層的代表的是策略級別的系統。
注意圖中的依賴方向指出，代碼依賴只能使由外向內。在實踐中，這意味著你需要把描述業務邏輯的代碼從具體交付機制（UI是web還是app，數據存放在數據庫還是NoSql，等等）中分離出來。
這樣能確保你的業務規則能獨立存在，而不依賴於具體的框架選擇和實現。
這樣做有以下好處：
- 分離關注點。
- 業務規則代碼只描述業務領域，不關注其他。
- 在更換數據存儲或web框架時，不需要改變業務邏輯代碼。
- 業務規則易於測試。
- 業務規則易於重構。
向內依賴規則不僅限制業務規則，其他各處也都需要遵循。但隔離業務規則是Clean Architecture提供的最有價值的一點。
分享到:
閱讀更多 程序魚 的文章
