クリーンなアーキテクチャ: どこから始めればよいでしょうか?-Python チュートリアル-php.cn

クリーンなアーキテクチャ: どこから始めればよいでしょうか?

Barbara Streisand

リリース： 2024-12-07 09:59:15

オリジナル

1005 人が閲覧しました

Clean architecture: Where to start ?

前の投稿では次のようになりました。

私たちの問題領域: いくつかの要件がある ToDo アプリケーション
Python および Python Polylith を使用するように構成された基本的なリポジトリ。

したがって、いくつかの決定は処理されます。いくつかのツールがあり、リポジトリがどのようなものになるか決定しました。

これは、Polylith について私が気に入っている点の 1 つです。コーディングしている内容や組織の規模に関係なく、複数のリポジトリが必要な場合でも、すべてのリポジトリが同じように見えます。

FastAPI、Flask、または Django を使用しているか、単一または複数のライブラリを構築しているか、または Celery でバックグラウンドタスクを実行しているかに関係なく、リポジトリ構造は一貫しています。

重要な利点の 1 つは、新しい開発者のオンボーディングプロセスが合理化されていることです。 Polylith を理解していると仮定すると、プロジェクトの構造にすぐに慣れるでしょう。再利用可能なコンポーネントはコンポーネントフォルダーにあり、エントリポイントはベースフォルダーにあり、デモスクリプトは開発フォルダーにあります。

エンティティ

ボブおじさんより「クリーンなアーキテクチャ」エンティティは私たちのアーキテクチャの基礎であり、私たちのアーキテクチャの最も内側の層です。したがって、それらから始める必要があります。Polylith では、エンティティはコンポーネントとして存在する必要があります。

コンポーネントはいくつありますか?

コンポーネントの数はソリューションの規模と複雑さに依存すると思います。ただし、エンティティ用の単一のポリリスコンポーネントから始めることをお勧めします。このアプローチは、特に小規模なプロジェクトの場合、明確で焦点を絞ったアーキテクチャを維持するのに役立ちます。

なぜエンティティに単一のコンポーネントを使用するのですか?

この層は、アプリケーション全体の基礎となるコアビジネスルールをカプセル化します。単一のコンポーネントに保持することで、一貫性が確保され、重複が回避されます。
単一のコンポーネントは他のすべてのレイヤーの依存関係となるため、依存関係の管理が簡素化されます。

サードパーティの依存関係を回避します。

外部の依存関係を最小限に抑え、アーキテクチャの柔軟性を高めるには、エンティティの表現に Python の標準ライブラリを使用するように努めてください。これには、dict、list、enum、関数、クラス、そして最近ではデータクラスなどのデータ構造の活用が含まれます。

Pydantic や Django Models などのサードパーティライブラリを避ける理由は何ですか?

外部フレームワークへの結合: これらのライブラリに依存すると、特定のフレームワークへの不必要な結合が発生する可能性があります。
複雑さの増加: 外部ライブラリにより、複雑さが増し、メンテナンスの問題が発生する可能性があります。
柔軟性の低下: 外部依存関係を制限することで、要件やテクノロジーの変化により簡単に適応できます。

これらの原則に従うことで、将来の変更にも対応できる堅牢で保守可能なアーキテクチャを作成できます。

ToDoエンティティ

私たちの例は簡単で、コアエンティティは Gordon の「todo アイテム」です。新しいコンポーネントをリポジトリに追加できますが、正しい名前を選択することが重要です。

「core」や「main」などの一般的な名前を使用したくなるかもしれませんが、ドメインコンテキスト内で意味のある名前を選択することが重要です。理想的には、これらの名前は、クライアントまたは製品所有者が使用する用語と一致している必要があります。ドメイン固有の名前を使用することで、コードの可読性と保守性が向上し、開発者と関係者の両方がプロジェクトの構造を理解しやすくなります。

リポジトリのワークスペース名は todo として定義されています。したがって、すべてのインポートは次の形式に従います:

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

ログイン後にコピー

この例では簡単にするために、コンポーネント名としてエンティティを使用します。ただし、実際のシナリオでは、ドメインを反映した命名規則を考慮してください。たとえば、アプリケーションがドキュメントの回復を中心に展開している場合は、recovery という名前のコンポーネントが適切です。同様に、ゲームアプリケーションでは、わかりやすくするためにトーナメント_エンティティを使用する場合があります。

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 ツールはテストサンプルを生成します。これは優れた機能です。この動作は、workspace.toml ファイルで [tool.polylith.test] セクションの Enabled = true 値を false に設定することで変更できます。

新しいエンティティコンポーネントに、__init__.py と core.py という 2 つのファイルが追加されます。ニーズに合わせて core.py モジュールの名前を変更できます。一般的な方法は、core.py などの他のモジュール内で内部組織を維持しながら、__init__.py を通じてパッケージのパブリック API を公開することです。

要件から、現時点では、ToDo 項目というエンティティが 1 つだけあります。

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

ログイン後にコピー

このような単純なエンティティをテストするのは不必要に思えるかもしれませんが、少なくともすべてのフィールドの存在をテストすることを好みます。これは、貢献者が少ない小規模なプロジェクトでは重要ではないように見えますが、多くの開発者がいる大規模なプロジェクトでは重大な問題を防ぐことができます。エンティティから 1 つのフィールドを削除すると、アプリケーションのさまざまな部分が誤って破損する可能性があります。

この部分のプルリクエストでは、このエンティティにいくつかの基本的なテストを追加したことがわかります。

いくつかのテストがすでに定義されているので、GitHub ワークフローを追加して、プルリクエストごとにテストを自動的に実行する機会を利用しました。