乾淨的架構：從哪裡開始？

在上一篇文章中我們有：

• 我們的問題領域：具有一些要求的 ToDo 應用程式
• 配置為使用 Python 和 Python Polylith 的基本儲存庫。

因此，一些決定已經完成。我們擁有一些工具並已經決定了儲存庫的外觀。

這是我喜歡 Polylith 的原因之一：無論您編碼什麼或您的組織有多大，所有儲存庫看起來都一樣 - 如果您需要多個儲存庫。

無論您使用 FastAPI、Flask 或 Django，建立單一或多個庫，還是使用 Celery 執行後台任務，您的儲存庫結構都是一致的。

主要優勢之一是簡化新開發人員的入職流程。假設他們掌握了 Polylith，他們很快就會熟悉專案結構：可重複使用元件位於 Components 資料夾中，入口點位於 bases 資料夾中，演示腳本位於development 資料夾中，等等。

實體

來自鮑伯叔叔的「清潔架構」實體是我們架構的基石，它們是我們架構的最內層。所以我們需要從它們開始，在 Polylith 中實體應該作為元件存在。

有幾個組件？

我相信組件的數量取決於解決方案的大小和複雜性。但是，我建議從實體的單一多塊組件開始。這種方法有助於保持清晰且重點突出的架構，特別是對於較小的專案。

為什麼實體只有一個組件？

• 該層封裝了對整個應用程式至關重要的核心業務規則。透過將其保留在單一組件中，可以確保一致性並避免重複。
• 單一元件簡化了依賴關係管理，因為它成為所有其他層的依賴關係。

避免第三方依賴。

為了最大限度地減少外部依賴並增強架構靈活性，請努力使用Python的標準函式庫來表示實體。這包括利用字典、列表、枚舉、函數、類別和最近的資料類別等資料結構。

為什麼要避免使用 Pydantic 或 Django Models 等第三方函式庫？

• 與外部框架的耦合：依賴這些函式庫可能會引入與特定框架不必要的耦合。
• 複雜性增加：外部函式庫可能會增加複雜性和潛在的維護問題。
• 靈活性降低：透過限制外部依賴，您可以更輕鬆地適應需求或技術的變化。

遵守這些原則，您可以創建一個健壯且可維護的架構，能夠適應未來的變化。

待辦事項實體

我們的範例很簡單，核心實體是 Gordon 的「待辦事項」。我們可以為我們的儲存庫添加一個新元件，但選擇正確的名稱至關重要。

雖然使用「core」或「main」等通用名稱可能很誘人，但選擇在網域上下文中有意義的名稱至關重要。理想情況下，這些名稱應與客戶或產品所有者使用的術語一致。透過使用特定於網域的名稱，我們增強了程式碼的可讀性和可維護性，使開發人員和利害關係人更容易理解專案的結構。

儲存庫工作區名稱定義為 todo。因此，我們所有的導入都將遵循以下格式：

from todo.XYZ import ...
import todo.XYZ

為了簡單起見，在本範例中，我們將使用實體作為元件名稱。但是，在現實場景中，請考慮反映您的網域的命名約定。例如，如果您的應用程式圍繞文件恢復，則名為恢復的元件將是合適的。同樣，為了清晰起見，遊戲應用程式可能會使用錦標賽實體。

使用 Python Polylith 建立元件很簡單：

poetry poly create component --name=entities
poetry poly sync
poetry install # it may be necessary

這將在元件資料夾中新增一個 python 套件，這是來源樹中的新條目：

./components
└── todo
    └── entities
        ├── __init__.py
        └── core.py
./test/components
└── todo
    └── entities
        ├── __init__.py
        └── test_core.py

python-polylith 工具將為我們產生測試範例，這是一個很好的功能。可以透過在 [tool.polylith.test] 部分中將enabled = true 值設為 false 來變更workspace.toml 檔案中的此行為。

在新的實體元件中，新增了兩個檔案：__init__.py 和 core.py。您可以重新命名 core.py 模組以更好地滿足您的需求。常見的做法是透過 __init__.py 公開套件的公共 API，同時在 core.py 等其他模組中維護內部組織。

根據要求，目前我們只有一個實體，即 ToDo 項：

@dataclass
class TodoItem:
    owner: str
    title: str
    description: str
    is_done: bool = False
    due_date: Optional[date] = None

測試這樣一個簡單的實體似乎沒有必要，但我更喜歡至少測試所有欄位的存在。雖然這在貢獻者較少的小型專案中似乎並不重要，但它可以防止在擁有許多開發人員的大型專案中出現重大問題。從實體中刪除單一欄位可能會無意中破壞應用程式的各個部分。

在這部分的拉取請求中，您將看到我為該實體添加了一些基本測試。

已經定義了一些測試，我藉此機會添加了 GitHub 工作流程來自動執行每個拉取請求的測試。

結論

• 應用程式基本實體
• CI 設定

接下來：我們來談談堅持

以上是乾淨的架構：從哪裡開始？的詳細內容。更多資訊請關注PHP中文網其他相關文章！