在上一篇文章中我們有：
因此，一些決定已經完成。我們擁有一些工具並已經決定了儲存庫的外觀。
這是我喜歡 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 工作流程來自動執行每個拉取請求的測試。
接下來：我們來談談堅持
以上是乾淨的架構：從哪裡開始？的詳細內容。更多資訊請關注PHP中文網其他相關文章！
