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

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

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

これは、Polylith について私が気に入っている點(diǎn)の 1 つです。コーディングしている內(nèi)容や組織の規(guī)模に関係なく、複數(shù)のリポジトリが必要な場(chǎng)合でも、すべてのリポジトリが同じように見えます。

FastAPI、Flask、または Django を使用しているか、単一または複數(shù)のライブラリを構(gòu)築しているか、または Celery でバックグラウンド タスクを?qū)g行しているかに関係なく、リポジトリ構(gòu)造は一貫しています。

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

エンティティ

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

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

コンポーネントの數(shù)はソリューションの規(guī)模と複雑さに依存すると思います。ただし、エンティティ用の単一のポリリス コンポーネントから始めることをお?jiǎng)幛幛筏蓼?。このアプローチは、特に小規(guī)模なプロジェクトの場(chǎng)合、明確で焦點(diǎn)を絞ったアーキテクチャを維持するのに役立ちます。

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

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

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

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

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

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

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

ToDoエンティティ

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

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

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

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

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

Python Polylith を使用したコンポーネントの作成は簡(jiǎn)単です:

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

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

要件から、現(xiàn)時(shí)點(diǎn)では、ToDo 項(xiàng)目というエンティティが 1 つだけあります。

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

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

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

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

結(jié)論

• アプリケーションの基本エンティティ
• CI セットアップ

次は、永続性について話しましょう

以上がクリーンなアーキテクチャ: どこから始めればよいでしょうか?の詳細(xì)內(nèi)容です。詳細(xì)については、PHP 中國(guó)語 Web サイトの他の関連記事を參照してください。