MVC サービス アーキテクチャは Symfony プロジェクトでは非常に一般的であるため、それが唯一の方法のように感じられます。シンプルで馴染みがあり、うまくいきます...うまくいかなくなるまでは。プロジェクトが成長するにつれて、亀裂が目立ち始めます。ビジネス ロジックがあちこちにあり、アプリの動作が不明確で、コードの保守が困難になります。これは最も一般的なアプローチですが、Symfony はこれに固執することを強制しません。
もっと良い方法があったとしたら?
MVC サービス アーキテクチャを使用する際の不満
ドメイン ロジックはあらゆる場所に分散されています
プロジェクトが成長するにつれて、ビジネス ロジックはコード ベース全体に広がる傾向があります。プロジェクトのすべての層 (コントローラー、サービス、フォーム、エンティティ) には、最終的にドメイン モデルの断片が含まれることになります。そのため、特定の部分に焦点を当てることがますます困難になります。
プロジェクトの境界が明確ではない
アーキテクチャが技術レイヤーを中心に編成されている場合、プロジェクトが成長するにつれて、さまざまなコンテキスト間の明確な境界を特定することが難しくなります。この明確さの欠如により、密接に結合されたコードとメンテナンスの問題が発生する可能性があります。
プロジェクトの動作が明確ではない
デフォルトのアーキテクチャは技術層を強調しているため、プロジェクトの動作を理解するのは非常に困難になります。特定のエンティティが特定のサービスによって管理されていると推測したり、データベース スキーマを推測したりすることはできますが、最も重要な側面であるプロジェクトの実際の動作は不明瞭で暗黙的なままです。
さまざまなライフサイクル
ビジネス ロジックがプロジェクト全体に散在し、実装の詳細と混在している場合、それらを独立して進化させることが困難になります。時間の経過とともに、ビジネス ロジックのライフサイクルは、実装の詳細 (フレームワーク、サードパーティ API、データベースなど) のライフサイクルよりもはるかに長くなる傾向があります。この不一致により、依存関係に小さな変更が発生するたびに、コードの大部分を書き直す必要があります。
アーキテクチャを構造化するためのより良い方法
ビジネスロジックを分離する
必要なときにビジネス ロジックに集中しやすくするために、最初のステップは、ビジネス ロジックをプロジェクトの残りの部分から分離することです。これを実現するには、Domain フォルダーを作成します。このフォルダーはプロジェクトの中核となり、実装の詳細に依存せず、純粋な PHP オブジェクトを使用してビジネス ロジックがモデル化されます。プロジェクトの残りの部分はこのフォルダーに依存しますが、ドメイン フォルダーは誰にも依存しません。
ドメイン フォルダー内では、ファイルは技術的な目的ではなくドメインの目的別にグループ化する必要があります。つまり、ここにはエンティティ、サービス、またはコントローラーのフォルダーはなく、機能またはドメインの概念に対応するフォルダー名のみが表示されます。
ドメインの正面玄関
プロジェクトの最も重要な側面は、プロジェクトが何をするか、つまり処理できるアクションです。これらのアクションはプロジェクトの動作を表し、ビジネス ロジックにアクセスする唯一の方法として機能します。これを反映するには、プロジェクトのすべての動作を明示的に示す Application フォルダーを作成します。たとえば、プロジェクトの新しい開発者として、このフォルダーを見れば、プロジェクトで何ができるかを一目で理解できるはずです。
外の世界とつながる
App フォルダーと Domain フォルダーを使用すると、ビジネス ロジックに集中しやすくなります。ただし、ある時点で、このビジネス ロジックは外部システムと対話する必要があります。これに対処するには、インフラストラクチャ という 3 番目のフォルダーを作成します。このフォルダーには、フレームワーク固有のコード、データベース接続、ライブラリなどの実装の詳細がすべて含まれています。
インフラストラクチャ フォルダー内のファイルは、アプリ ファイルとドメイン ファイルに依存します。たとえば、アプリケーション フォルダーからアプリケーション ハンドラーを呼び出したり、ドメイン フォルダーで定義されたインターフェイスを実装したりする場合があります。
具体的には、Symfony では、Controller フォルダーを変更し、どのサービスがどのインターフェースを実装するかを宣言する必要があります。
# config/routes.yaml controllers: resource: path: ../src/Catalog/Infrastructure/Controller/ namespace: App\Catalog\Infrastructure\Controller type: attribute
境界を明らかにする
プロジェクトが進化するにつれて、ビジネス ロジックの一部がアーキテクチャ内で独自のスペースを必要とすることに気づくかもしれません。良い指標は、同じ用語が文脈に応じて異なる意味を持ち始める時期です。たとえば、「製品」という単語は、工場製品、倉庫製品、または電子商取引製品を指す場合があり、それぞれに独自のモデルが必要です。神のオブジェクトも良い指標になる可能性があります。 Symfony プロジェクトでは、User クラスでこの種の問題がよく発生します。
これが起こったら、それを抽出してビジネス ロジックを独自に進化させます。
一部のコンテキストはプロジェクトの中核を形成し、他のコンテキストはそれをサポートします。 Auth などの汎用コンテキストはドメインの中心ではないため、より単純なアーキテクチャを使用できます
この図では、Auth コンテキストが標準の Symfony 構造を使用し、Order コンテキストと Catalog コンテキストがドメイン中心のアーキテクチャを使用し、 Shipping コンテキストが機能中心のアーキテクチャを使用していることがわかります。
インクリメンタルモジュール性
特定のコンテキストが独立して拡張する必要がある点まで成長する場合は、それを別のデプロイメント ユニットに分割することを検討してください。
ただし、このステップを急いで行わないでください。まずプロジェクトをモジュール化して、コンテキストを個別に拡張する必要があることに気付いた場合は、コンテキストを個別にデプロイします。
2 つのチームが同じコードベースで共同作業するのに苦労しているなど、組織上の課題が発生した場合にのみ、コードベースを分割します。
さらに遠くへ
- Simon Brown - モジュール式モノリス
コンセプト
これらのソリューションを検討する中で、私たちはいくつかのクラフトマンシップの概念を適用しました。それぞれについて詳しく説明できるように、それらに名前を付けて簡単に説明しましょう。
ユビキタス言語
この珍しい用語の背後には、非常に単純な概念があります。ユビキタス言語は、チームがドメイン モデルを説明するために使用する語彙です。この語彙は文書化され、製品に関する会話やコードベースなど、あらゆる場所で一貫して使用される必要があります。
具体的には、境界コンテキストのルートにマークダウン ファイルを作成し、製品担当者、ドメインの専門家、技術チームを集めてプロジェクトの各コンセプトを定義します。
さらに遠くへ
- エリック・エヴァンス - DDD - 第 2 章 : コミュニケーションと言語の使用
- マーティン・ファウラー - ユビキタス言語
境界付きコンテキスト
境界付きコンテキストは、プロジェクト内の言語境界を定義し、ユビキタス言語が一致しなくなったシステムの部分を分離します。コンテキスト マップやイベント ストーミングなどのツールは、これらの境界を特定するのに役立ちます。
境界のあるコンテキストは抽象的な概念です。モジュール式モノリスの単純なフォルダーからマイクロサービス アーキテクチャのクラスターまで、さまざまな方法で実装できます。
さらに遠くへ
- エリック・エヴァンス - DDD - パート IV : 戦略的デザイン
- Vaughn Vernon - IDDD - 第 2 章 : ドメイン、サブドメイン、および境界付きコンテキスト
- Martin Fowler - 境界のあるコンテキスト
ポートとアダプター、六角形、オニオン、クリーンなアーキテクチャ
これらのアーキテクチャはすべて、ビジネス ロジックを実装の詳細から分離することを目的としています。ポートとアダプター、ヘキサゴナル、またはクリーン アーキテクチャのいずれを使用する場合でも、中心となるアイデアは、ビジネス ロジック フレームワークに依存せず、テストを容易にすることです。
これを念頭に置けば、あらゆる実装があり、最適なものはコンテキストと好みによって異なります。このアーキテクチャの主な利点は、ビジネス ロジックを分離することで、より効率的なテストが可能になることです。
さらに遠くへ
- アリスター・コックバーン - 六角形の建築
- ボブおじさん - クリーンな建築
- Herberto Graca - DDD、Hexagonal、Onion、Clean、CQRS、…すべてをまとめる方法
叫ぶ建築
ビジネス ロジックを「叫ぶ」ためにフォルダーとファイルを整理するというアイデアは、スクリーミング アーキテクチャとして知られています。この概念は、コードの構造によってプロジェクトの目的が即座に明確になる必要があることを強調しています。目標は、新しい開発者がプロジェクトの内容を一目で理解できるようにすることです。
このテーマに関するボブおじさんの記事を読むことを強くお勧めします。彼の住宅計画との比較は特に洞察力に富んでいます。
さらに遠くへ
- アンクル・ボブ - 叫ぶ建築
垂直スライシングアーキテクチャ
垂直スライスにより、プロジェクトが機能ごとに整理され、各機能が独立して進化できるようになります。これにより、複雑さと成熟度に基づいて、さまざまなアーキテクチャをさまざまな機能に適用できます。
このアイデアは興味深いものですが、このようなアーキテクチャを効果的に実装し、維持するには高度なスキルを持ったエンジニアが必要です。
さらに遠くへ
- ジミー・ボガード - 垂直スライス建築
- CodeOpinion - レイヤーではなく垂直スライス アーキテクチャ!
最終的な考え
Symfony プロジェクトを構造化する方法は、そのスケーラビリティ、保守性、明瞭さに大きな影響を与えます。ビジネス ロジックを分離し、動作を明示することで、理解しやすく進化しやすいシステムを作成できます。
これらのアイデアに慣れていない場合でも、心配しないでください。ソフトウェアのクラフトマンシップは目的地ではなく旅です。最初は概念が難しそうに思えるかもしれませんが、それぞれの概念はビジネスにより多くの価値を提供するのに役立ちます。
ご質問がありますか、またはあなたの経験を共有したいですか?コメント欄に書き込んでください!次の記事もお楽しみに?
以上がSymfony プロジェクトを構成する別の方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

PHPでは、特性は方法が必要な状況に適していますが、継承には適していません。 1)特性により、クラスの多重化方法が複数の継承の複雑さを回避できます。 2)特性を使用する場合、メソッドの競合に注意を払う必要があります。メソッドの競合は、代替およびキーワードとして解決できます。 3)パフォーマンスを最適化し、コードメンテナビリティを改善するために、特性の過剰使用を避け、その単一の責任を維持する必要があります。

依存関係噴射コンテナ(DIC)は、PHPプロジェクトで使用するオブジェクト依存関係を管理および提供するツールです。 DICの主な利点には、次のものが含まれます。1。デカップリング、コンポーネントの独立したもの、およびコードの保守とテストが簡単です。 2。柔軟性、依存関係を交換または変更しやすい。 3.テスト可能性、単体テストのために模擬オブジェクトを注入するのに便利です。

SplfixedArrayは、PHPの固定サイズの配列であり、高性能と低いメモリの使用が必要なシナリオに適しています。 1)動的調整によって引き起こされるオーバーヘッドを回避するために、作成時にサイズを指定する必要があります。 2)C言語アレイに基づいて、メモリと高速アクセス速度を直接動作させます。 3)大規模なデータ処理とメモリに敏感な環境に適していますが、サイズが固定されているため、注意して使用する必要があります。

PHPは、$ \ _ファイル変数を介してファイルのアップロードを処理します。セキュリティを確保するための方法には次のものが含まれます。1。アップロードエラー、2。ファイルの種類とサイズを確認する、3。ファイル上書きを防ぐ、4。ファイルを永続的なストレージの場所に移動します。

JavaScriptでは、nullcoalescingoperator(??)およびnullcoalescingsignmentoperator(?? =)を使用できます。 1.??最初の非潜水金または非未定されたオペランドを返します。 2.??これらの演算子は、コードロジックを簡素化し、読みやすさとパフォーマンスを向上させます。

XSS攻撃を防ぎ、リソースのロードを制限し、ウェブサイトのセキュリティを改善できるため、CSPは重要です。 1.CSPはHTTP応答ヘッダーの一部であり、厳格なポリシーを通じて悪意のある行動を制限します。 2。基本的な使用法は、同じ起源からのロードリソースのみを許可することです。 3.高度な使用法は、特定のドメイン名がスクリプトやスタイルをロードできるようにするなど、より微調整された戦略を設定できます。 4。CSPポリシーをデバッグおよび最適化するには、コンテンツセキュリティポリシーレポートのみのヘッダーを使用します。

HTTPリクエストメソッドには、それぞれリソースを取得、送信、更新、削除するために使用されるGET、POST、PUT、および削除が含まれます。 1. GETメソッドは、リソースを取得するために使用され、読み取り操作に適しています。 2. POSTメソッドはデータの送信に使用され、新しいリソースを作成するためによく使用されます。 3. PUTメソッドは、リソースの更新に使用され、完全な更新に適しています。 4.削除メソッドは、リソースの削除に使用され、削除操作に適しています。

HTTPSは、HTTPに基づいてセキュリティレイヤーを追加するプロトコルであり、主に暗号化されたデータを介してユーザーのプライバシーとデータセキュリティを保護します。その作業原則には、TLSの握手、証明書の確認、暗号化された通信が含まれます。 HTTPSを実装する場合、証明書管理、パフォーマンスへの影響、および混合コンテンツの問題に注意を払う必要があります。


ホットAIツール

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

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

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

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

人気の記事

ホットツール

AtomエディタMac版ダウンロード
最も人気のあるオープンソースエディター

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

ゼンドスタジオ 13.0.1
強力な PHP 統合開発環境

SecLists
SecLists は、セキュリティ テスターの究極の相棒です。これは、セキュリティ評価中に頻繁に使用されるさまざまな種類のリストを 1 か所にまとめたものです。 SecLists は、セキュリティ テスターが必要とする可能性のあるすべてのリストを便利に提供することで、セキュリティ テストをより効率的かつ生産的にするのに役立ちます。リストの種類には、ユーザー名、パスワード、URL、ファジング ペイロード、機密データ パターン、Web シェルなどが含まれます。テスターはこのリポジトリを新しいテスト マシンにプルするだけで、必要なあらゆる種類のリストにアクセスできるようになります。

SublimeText3 中国語版
中国語版、とても使いやすい

ホットトピック



