在上一篇文章中我們有：

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

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

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

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

主要優(yōu)勢之一是簡化新開發(fā)人員的入職流程。假設他們掌握了 Polylith，他們將很快熟悉項目結構：可重用組件位于 Components 文件夾中，入口點位于 bases 文件夾中，演示腳本位于development 文件夾中，等等。

實體

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

有多少個組件？

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

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

• 該層封裝了對整個應用程序至關重要的核心業(yè)務規(guī)則。通過將其保留在單個組件中，可以確保一致性并避免重復。
• 單個組件簡化了依賴關系管理，因為它成為所有其他層的依賴關系。

避免第三方依賴。

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

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

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

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

待辦事項實體

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

雖然使用“core”或“main”等通用名稱可能很誘人，但選擇在域上下文中有意義的名稱至關重要。理想情況下，這些名稱應與客戶或產(chǎn)品所有者使用的術語一致。通過使用特定于域的名稱，我們增強了代碼的可讀性和可維護性，使開發(fā)人員和利益相關者更容易理解項目的結構。

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

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

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

使用 Python Polylith 創(chuàng)建組件很簡單：

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 等其他模塊中維護內部組織。

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

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

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

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

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

結論

• 應用程序基本實體
• CI 設置

接下來：我們來談談堅持

以上是干凈的架構：從哪里開始？的詳細內容。更多信息請關注PHP中文網(wǎng)其他相關文章！