在上一篇文章中我們有：

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

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

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

無論您使用 FastAPI、Flask 或 Django，建立單一或多個庫，還是使用 Celery 執(zhí)行後臺任務(wù)，您的儲存庫結(jié)構(gòu)都是一致的。

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

實體

來自鮑伯叔叔的「清潔架構(gòu)」實體是我們架構(gòu)的基石，它們是我們架構(gòu)的最內(nèi)層。所以我們需要從它們開始，在 Polylith 中實體應(yīng)該作為元件存在。

有幾個組件？

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

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

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

避免第三方依賴。

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

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

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

遵守這些原則，您可以創(chuàng)建一個健壯且可維護的架構(gòu)，能夠適應(yīng)未來的變化。

待辦事項實體

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

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

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

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

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

使用 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 工具將為我們產(chǎn)生測試範例，這是一個很好的功能?？梢酝高^在 [tool.polylith.test] 部分中將enabled = true 值設(shè)為 false 來變更workspace.toml 檔案中的此行為。

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

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

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

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

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

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

結(jié)論

• 應(yīng)用程式基本實體
• CI 設(shè)定

接下來：我們來談?wù)剤猿?/p>

以上是乾淨的架構(gòu)：從哪裡開始？的詳細內(nèi)容。更多資訊請關(guān)注PHP中文網(wǎng)其他相關(guān)文章！