検索
ホームページバックエンド開発PHPチュートリアルSymfony プロジェクトを構成する別の方法

MVC サービス アーキテクチャは Symfony プロジェクトでは非常に一般的であるため、それが唯一の方法のように感じられます。シンプルで馴染みがあり、うまくいきます...うまくいかなくなるまでは。プロジェクトが成長するにつれて、亀裂が目立ち始めます。ビジネス ロジックがあちこちにあり、アプリの動作が不明確で、コードの保守が困難になります。これは最も一般的なアプローチですが、Symfony はこれに固執することを強制しません。

もっと良い方法があったとしたら?


MVC サービス アーキテクチャを使用する際の不満

ドメイン ロジックはあらゆる場所に分散されています

プロジェクトが成長するにつれて、ビジネス ロジックはコード ベース全体に広がる傾向があります。プロジェクトのすべての層 (コントローラー、サービス、フォーム、エンティティ) には、最終的にドメイン モデルの断片が含まれることになります。そのため、特定の部分に焦点を当てることがますます困難になります。

プロジェクトの境界が明確ではない

アーキテクチャが技術レイヤーを中心に編成されている場合、プロジェクトが成長するにつれて、さまざまなコンテキスト間の明確な境界を特定することが難しくなります。この明確さの欠如により、密接に結合されたコードとメンテナンスの問題が発生する可能性があります。

Another Way to Structure your Symfony Project

プロジェクトの動作が明確ではない

デフォルトのアーキテクチャは技術層を強調しているため、プロジェクトの動作を理解するのは非常に困難になります。特定のエンティティが特定のサービスによって管理されていると推測したり、データベース スキーマを推測したりすることはできますが、最も重要な側面であるプロジェクトの実際の動作は不明瞭で暗黙的なままです。

Another Way to Structure your Symfony Project

さまざまなライフサイクル

ビジネス ロジックがプロジェクト全体に散在し、実装の詳細と混在している場合、それらを独立して進化させることが困難になります。時間の経過とともに、ビジネス ロジックのライフサイクルは、実装の詳細 (フレームワーク、サードパーティ API、データベースなど) のライフサイクルよりもはるかに長くなる傾向があります。この不一致により、依存関係に小さな変更が発生するたびに、コードの大部分を書き直す必要があります。


アーキテクチャを構造化するためのより良い方法

ビジネスロジックを分離する

必要なときにビジネス ロジックに集中しやすくするために、最初のステップは、ビジネス ロジックをプロジェクトの残りの部分から分離することです。これを実現するには、Domain フォルダーを作成します。このフォルダーはプロジェクトの中核となり、実装の詳細に依存せず、純粋な PHP オブジェクトを使用してビジネス ロジックがモデル化されます。プロジェクトの残りの部分はこのフォルダーに依存しますが、ドメイン フォルダーは誰にも依存しません。

ドメイン フォルダー内では、ファイルは技術的な目的ではなくドメインの目的別にグループ化する必要があります。つまり、ここにはエンティティ、サービス、またはコントローラーのフォルダーはなく、機能またはドメインの概念に対応するフォルダー名のみが表示されます。

Another Way to Structure your Symfony Project

ドメインの正面玄関

プロジェクトの最も重要な側面は、プロジェクトが何をするか、つまり処理できるアクションです。これらのアクションはプロジェクトの動作を表し、ビジネス ロジックにアクセスする唯一の方法として機能します。これを反映するには、プロジェクトのすべての動作を明示的に示す Application フォルダーを作成します。たとえば、プロジェクトの新しい開発者として、このフォルダーを見れば、プロジェクトで何ができるかを一目で理解できるはずです。

Another Way to Structure your Symfony Project

外の世界とつながる

App フォルダーと Domain フォルダーを使用すると、ビジネス ロジックに集中しやすくなります。ただし、ある時点で、このビジネス ロジックは外部システムと対話する必要があります。これに対処するには、インフラストラクチャ という 3 番目のフォルダーを作成します。このフォルダーには、フレームワーク固有のコード、データベース接続、ライブラリなどの実装の詳細がすべて含まれています。

インフラストラクチャ フォルダー内のファイルは、アプリ ファイルとドメイン ファイルに依存します。たとえば、アプリケーション フォルダーからアプリケーション ハンドラーを呼び出したり、ドメイン フォルダーで定義されたインターフェイスを実装したりする場合があります。

Another Way to Structure your Symfony Project

具体的には、Symfony では、Controller フォルダーを変更し、どのサービスがどのインターフェースを実装するかを宣言する必要があります。

# config/routes.yaml

controllers:
    resource:
        path: ../src/Catalog/Infrastructure/Controller/
        namespace: App\Catalog\Infrastructure\Controller
    type: attribute

境界を明らかにする

プロジェクトが進化するにつれて、ビジネス ロジックの一部がアーキテクチャ内で独自のスペースを必要とすることに気づくかもしれません。良い指標は、同じ用語が文脈に応じて異なる意味を持ち始める時期です。たとえば、「製品」という単語は、工場製品、倉庫製品、または電子商取引製品を指す場合があり、それぞれに独自のモデルが必要です。神のオブジェクトも良い指標になる可能性があります。 Symfony プロジェクトでは、User クラスでこの種の問題がよく発生します。

これが起こったら、それを抽出してビジネス ロジックを独自に進化させます。

一部のコンテキストはプロジェクトの中核を形成し、他のコンテキストはそれをサポートします。 Auth などの汎用コンテキストはドメインの中心ではないため、より単純なアーキテクチャを使用できます

Another Way to Structure your Symfony Project

この図では、Auth コンテキストが標準の Symfony 構造を使用し、Order コンテキストと Catalog コンテキストがドメイン中心のアーキテクチャを使用し、 Shipping コンテキストが機能中心のアーキテクチャを使用していることがわかります。

インクリメンタルモジュール性

特定のコンテキストが独立して拡張する必要がある点まで成長する場合は、それを別のデプロイメント ユニットに分割することを検討してください。

ただし、このステップを急いで行わないでください。まずプロジェクトをモジュール化して、コンテキストを個別に拡張する必要があることに気付いた場合は、コンテキストを個別にデプロイします。
2 つのチームが同じコードベースで共同作業するのに苦労しているなど、組織上の課題が発生した場合にのみ、コードベースを分割します。

Another Way to Structure your Symfony Project

さらに遠くへ
  • Simon Brown - モジュール式モノリス

コンセプト

これらのソリューションを検討する中で、私たちはいくつかのクラフトマンシップの概念を適用しました。それぞれについて詳しく説明できるように、それらに名前を付けて簡単に説明しましょう。

ユビキタス言語

この珍しい用語の背後には、非常に単純な概念があります。ユビキタス言語は、チームがドメイン モデルを説明するために使用する語彙です。この語彙は文書化され、製品に関する会話やコードベースなど、あらゆる場所で一貫して使用される必要があります。

具体的には、境界コンテキストのルートにマークダウン ファイルを作成し、製品担当者、ドメインの専門家、技術チームを集めてプロジェクトの各コンセプトを定義します。

さらに遠くへ

  • エリック・エヴァンス - DDD - 第 2 章 : コミュニケーションと言語の使用
  • マーティン・ファウラー - ユビキタス言語

境界付きコンテキスト

境界付きコンテキストは、プロジェクト内の言語境界を定義し、ユビキタス言語が一致しなくなったシステムの部分を分離します。コンテキスト マップやイベント ストーミングなどのツールは、これらの境界を特定するのに役立ちます。

境界のあるコンテキストは抽象的な概念です。モジュール式モノリスの単純なフォルダーからマイクロサービス アーキテクチャのクラスターまで、さまざまな方法で実装できます。

さらに遠くへ

  • エリック・エヴァンス - DDD - パート IV : 戦略的デザイン
  • Vaughn Vernon - IDDD - 第 2 章 : ドメイン、サブドメイン、および境界付きコンテキスト
  • Martin Fowler - 境界のあるコンテキスト

ポートとアダプター、六角形、オニオン、クリーンなアーキテクチャ

これらのアーキテクチャはすべて、ビジネス ロジックを実装の詳細から分離することを目的としています。ポートとアダプター、ヘキサゴナル、またはクリーン アーキテクチャのいずれを使用する場合でも、中心となるアイデアは、ビジネス ロジック フレームワークに依存せず、テストを容易にすることです。

これを念頭に置けば、あらゆる実装があり、最適なものはコンテキストと好みによって異なります。このアーキテクチャの主な利点は、ビジネス ロジックを分離することで、より効率的なテストが可能になることです。

さらに遠くへ

  • アリスター・コックバーン - 六角形の建築
  • ボブおじさん - クリーンな建築
  • Herberto Graca - DDD、Hexagonal、Onion、Clean、CQRS、…すべてをまとめる方法

叫ぶ建築

ビジネス ロジックを「叫ぶ」ためにフォルダーとファイルを整理するというアイデアは、スクリーミング アーキテクチャとして知られています。この概念は、コードの構造によってプロジェクトの目的が即座に明確になる必要があることを強調しています。目標は、新しい開発者がプロ​​ジェクトの内容を一目で理解できるようにすることです。

このテーマに関するボブおじさんの記事を読むことを強くお勧めします。彼の住宅計画との比較は特に洞察力に富んでいます。

さらに遠くへ

  • アンクル・ボブ - 叫ぶ建築

垂直スライシングアーキテクチャ

垂直スライスにより、プロジェクトが機能ごとに整理され、各機能が独立して進化できるようになります。これにより、複雑さと成熟度に基づいて、さまざまなアーキテクチャをさまざまな機能に適用できます。

このアイデアは興味深いものですが、このようなアーキテクチャを効果的に実装し、維持するには高度なスキルを持ったエンジニアが必要です。

さらに遠くへ

  • ジミー・ボガード - 垂直スライス建築
  • CodeOpinion - レイヤーではなく垂直スライス アーキテクチャ!

最終的な考え

Symfony プロジェクトを構造化する方法は、そのスケーラビリティ、保守性、明瞭さに大きな影響を与えます。ビジネス ロジックを分離し、動作を明示することで、理解しやすく進化しやすいシステムを作成できます。

これらのアイデアに慣れていない場合でも、心配しないでください。ソフトウェアのクラフトマンシップは目的地ではなく旅です。最初は概念が難しそうに思えるかもしれませんが、それぞれの概念はビジネスにより多くの価値を提供するのに役立ちます。

ご質問がありますか、またはあなたの経験を共有したいですか?コメント欄に書き込んでください!次の記事もお楽しみに?

以上がSymfony プロジェクトを構成する別の方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。
11ベストPHP URLショートナースクリプト(無料およびプレミアム)11ベストPHP URLショートナースクリプト(無料およびプレミアム)Mar 03, 2025 am 10:49 AM

多くの場合、キーワードと追跡パラメーターで散らかった長いURLは、訪問者を阻止できます。 URL短縮スクリプトはソリューションを提供し、ソーシャルメディアやその他のプラットフォームに最適な簡潔なリンクを作成します。 これらのスクリプトは、個々のWebサイトにとって価値があります

Instagram APIの紹介Instagram APIの紹介Mar 02, 2025 am 09:32 AM

2012年のFacebookによる有名な買収に続いて、Instagramはサードパーティの使用のために2セットのAPIを採用しました。これらはInstagramグラフAPIとInstagram Basic Display APIです。

Laravelでフラッシュセッションデータを使用しますLaravelでフラッシュセッションデータを使用しますMar 12, 2025 pm 05:08 PM

Laravelは、直感的なフラッシュメソッドを使用して、一時的なセッションデータの処理を簡素化します。これは、アプリケーション内に簡単なメッセージ、アラート、または通知を表示するのに最適です。 データは、デフォルトで次の要求のためにのみ持続します。 $リクエスト -

LaravelのバックエンドでReactアプリを構築する:パート2、ReactLaravelのバックエンドでReactアプリを構築する:パート2、ReactMar 04, 2025 am 09:33 AM

これは、LaravelバックエンドとのReactアプリケーションの構築に関するシリーズの2番目と最終部分です。シリーズの最初の部分では、基本的な製品上場アプリケーションのためにLaravelを使用してRESTFUL APIを作成しました。このチュートリアルでは、開発者になります

Laravelテストでの簡略化されたHTTP応答のモッキングLaravelテストでの簡略化されたHTTP応答のモッキングMar 12, 2025 pm 05:09 PM

Laravelは簡潔なHTTP応答シミュレーション構文を提供し、HTTP相互作用テストを簡素化します。このアプローチは、テストシミュレーションをより直感的にしながら、コード冗長性を大幅に削減します。 基本的な実装は、さまざまな応答タイプのショートカットを提供します。 Illuminate \ support \ facades \ httpを使用します。 http :: fake([[ 'google.com' => 'hello world'、 'github.com' => ['foo' => 'bar']、 'forge.laravel.com' =>

PHPのカール:REST APIでPHPカール拡張機能を使用する方法PHPのカール:REST APIでPHPカール拡張機能を使用する方法Mar 14, 2025 am 11:42 AM

PHPクライアントURL(CURL)拡張機能は、開発者にとって強力なツールであり、リモートサーバーやREST APIとのシームレスな対話を可能にします。尊敬されるマルチプロトコルファイル転送ライブラリであるLibcurlを活用することにより、PHP Curlは効率的なexecuを促進します

Codecanyonで12の最高のPHPチャットスクリプトCodecanyonで12の最高のPHPチャットスクリプトMar 13, 2025 pm 12:08 PM

顧客の最も差し迫った問題にリアルタイムでインスタントソリューションを提供したいですか? ライブチャットを使用すると、顧客とのリアルタイムな会話を行い、すぐに問題を解決できます。それはあなたがあなたのカスタムにより速いサービスを提供することを可能にします

2025 PHP状況調査の発表2025 PHP状況調査の発表Mar 03, 2025 pm 04:20 PM

2025 PHP Landscape Surveyは、現在のPHP開発動向を調査しています。 開発者や企業に洞察を提供することを目的とした、フレームワークの使用、展開方法、および課題を調査します。 この調査では、現代のPHP Versioの成長が予想されています

See all articles

ホットAIツール

Undresser.AI Undress

Undresser.AI Undress

リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover

AI Clothes Remover

写真から衣服を削除するオンライン AI ツール。

Undress AI Tool

Undress AI Tool

脱衣画像を無料で

Clothoff.io

Clothoff.io

AI衣類リムーバー

AI Hentai Generator

AI Hentai Generator

AIヘンタイを無料で生成します。

ホットツール

Dreamweaver Mac版

Dreamweaver Mac版

ビジュアル Web 開発ツール

Safe Exam Browser

Safe Exam Browser

Safe Exam Browser は、オンライン試験を安全に受験するための安全なブラウザ環境です。このソフトウェアは、あらゆるコンピュータを安全なワークステーションに変えます。あらゆるユーティリティへのアクセスを制御し、学生が無許可のリソースを使用するのを防ぎます。

ゼンドスタジオ 13.0.1

ゼンドスタジオ 13.0.1

強力な PHP 統合開発環境

SAP NetWeaver Server Adapter for Eclipse

SAP NetWeaver Server Adapter for Eclipse

Eclipse を SAP NetWeaver アプリケーション サーバーと統合します。

SublimeText3 英語版

SublimeText3 英語版

推奨: Win バージョン、コードプロンプトをサポート!