Clean Architecture
Clean Architecture 是由軟體工程師 Robert C. Martin（Uncle Bob）提出的一種軟體設計架構，目的是建立可維護、可測試、可擴展的軟體系統。它強調將系統分為不同的層次，每個層次擁有特定的職責，同時確保業務邏輯獨立於技術細節。
Clean Architecture 的主要特點包括以下幾個層次：
- Entity：包含應用程式的業務實體，這是與業務邏輯直接相關的部分。這一層不應該包含與框架或技術相關的程式碼。
- Use Case：包含應用程式的業務邏輯，實現了系統的各種使用情境。這一層是 Clean Architecture 中的核心，並且是最接近業務邏輯的地方。
- Interface：包含與系統的外部交互相關的程式碼，例如使用者介面、控制器、閘道等。這一層負責將用戶輸入轉換為用例的調用，以及將用例的輸出轉換為適當的顯示。
- Frameworks and Drivers：包含與外部工具、框架和資源庫相關的程式碼。這一層包含所有與技術相關的實現細節，但應該保持與業務邏輯的獨立性。
Clean Architecture 的關鍵概念是依賴性反轉，即高層次的模組不應該依賴於低層次的實現，而是相反。這有助於實現可測試性和可維護性，同時確保系統的核心業務邏輯不受技術細節的影響。
如何把程式碼寫好？
你有聞到程式碼的壞味道嗎？
要如何提升程式碼的可讀性、可維護性和重用性，要怎麼判別程式碼的好壞？
SOLID 原則幫助我們回答了這個問題
S.O.L.I.D 原則
SOLID 原則則是一組設計原則，有助於實現Clean Architecture。以下是 SOLID 原則的簡要說明，以便更好地理解其在 Clean Architecture 中的應用：
- 單一職責原則 (Single Responsibility Principle — SRP)：每個類別或模組應該僅有一個改變的理由，也就是說，它應該只有一個職責。在 Clean Architecture 中，這意味著每一層（例如，實體、用例、介面等）都應該只負責一個特定的關注點。
- 開放/封閉原則 (Open/Closed Principle — OCP)：系統的設計應該是開放擴展的，但封閉修改的。這表示，當需要新增功能時，應該透過擴展現有的代碼而非修改現有的代碼。在 Clean Architecture 中，這鼓勵我們透過新增新的用例、實體等，而不是修改現有的業務邏輯。
- 里氏替換原則 (Liskov Substitution Principle — LSP)：衍生類別應該能夠替換基類別而不影響程式的正確性。在 Clean Architecture 中，這表示你可以更換不同的實現方式，而不影響用例或其他高層次的模組。
- 介面隔離原則 (Interface Segregation Principle — ISP)：不應該強迫一個類別實現它用不到的介面。換句話說，一個類別不應該被迫依賴它不使用的方法。在 Clean Architecture 中，這表示介面應該被設計得小而專注，每個用例或模組僅需實現它們需要的部分。
- 依賴反轉原則 (Dependency Inversion Principle — DIP)：高層次的模組不應該依賴於低層次的模組，兩者都應該依賴於抽象。在 Clean Architecture 中，這表示高層次的用例或實體不應該直接依賴低層次的實現，而應該透過介面或抽象來實現。
