賢いPHPアプリケーションの組織構造？

無数のオープンソースプロジェクトに利用できる100万のファイルシステム構造があります。モジュール、言語ファイル、ドメイン、サードパーティライブラリ、移行、国際化、バックアップ、システムの他の部分へのsyslinkなどのものが、プロジェクトのファイルシステムを編成する多くのアプローチを生み出しています。

PHP開発者として、プロジェクト間で何らかの標準化が出現し始めているのではないかと思っています。PSR-0 、我々は最終的にファイルを命名し、ロードするための標準を持っている-しかし、それシステムやそれらがどのように正気の方法で処理することができますを構成するコンポーネントの残りの部分についての私の知識に何もありません。

私たちが扱っているのはMVCだけではありません。これらのすべてを正しく処理する大規模なプロジェクトの例にはどのようなものがありますか？

「依存する」ため、プロジェクトのレイアウト方法を標準化することは実際には不可能です。

標準的な構造を導入しても、その一部が開発中の要件に関連していない場合、不要なノイズが追加される可能性があります。同様に、標準が幅広いプロジェクトで機能する必要がある場合は、あまりにも多くの異なるシナリオを組み込む必要があります。

開発者としての私たちの仕事は、パターンとベストプラクティスを探し、それらを手元のタスクに適用することです。私たちは経験と専門知識を使用して、取り組んでいるプロジェクトに適したファイルシステム構造を選択します。

標準化の取り組みはあまり進んでいないようで、正直なところ、利点はわかりません。守るべきルールは1つだけです。つまり、docrootの下には、そこに属していないものを置かないでください（基本的なセキュリティ対策）。

それ以外は、このプロジェクトにとって意味のあるものを使用します。

（フレームワークまたはアドホックのいずれかを介して）MVCを使用している場合、/ models、/ views、および/ controllersを使用した基本構造が理にかなっています。しかし、そうでない場合でも、通常、データエンティティにマップするクラスを備えたある種のデータアクセスレイヤーがあります。それらのディレクトリがあることは理にかなっています。また、通常はビジネスロジッククラスとユーティリティ関数がたくさんあるので、それらの別のディレクトリを作成します。テンプレートシステムを使用する場合、テンプレートは別のディレクトリに移動します。そして、おそらくあなたはすべてのサードパーティのライブラリを置く「ライブラリ」ディレクトリが必要です。（この時点に達したら、とにかくほとんどMVCを実行しています）。

プロジェクトが本当に大きい場合は、おそらく機能的なサブモジュールに分割できます。サブモジュールがかなり独立している場合は、代わりにそれらをトップレベルとして使用し、共通コード用のディレクトリを1つ追加することは理にかなっています。

最も一般的な2つのアプリケーションフレームワークのプロジェクトレイアウトに従うことができます。

1. Zend Framework- http://www.framework.zend.com/manual/en/project-structure.project.html
2. symfony- http://symfony.com/doc/current/book/installation.html

これらは、ユーザーからのベストプラクティスとエクスペリエンスに基づいた拡張可能な構造を提供します