複数のZendアプリケーションコードの編成
過去1年間、私はすべてZendフレームワークに基づく一連のアプリケーションに取り組んでおり、すべてを使用しなくてもすべてのアプリケーションがアクセスする必要がある複雑なビジネスロジックを中心に（それぞれに複数のライブラリフォルダーを用意するよりも簡単です）アプリケーションはすべて共通のセンターでリンクされているため）。
プロジェクトの詳細については詳しく説明しませんが、コードを "グループ化"する方法について（プロジェクトだけで作業しているので）いくつかの情報を探しています。私は、依存関係を可能な限り取り除くような方法で、すべてを分割することを試みました。
私はそれを論理的に可能な限り分離したままにしようとしているので、自分の時間がアップする12か月の時間で、他の誰かが私が作成したものを拡張することに問題はありません。
構造例：
applicationStorage\ (contains all applications and associated data)
applicationStorage\Applications\ (contains the applications themselves)
applicationStorage\Applications\external\ (application grouping folder) (contains all external customer access applications)
applicationStorage\Applications\external\site\ (main external customer access application)
applicationStorage\Applications\external\site\Modules\
applicationStorage\Applications\external\site\Config\
applicationStorage\Applications\external\site\Layouts\
applicationStorage\Applications\external\site\ZendExtended\ (contains extended Zend classes specific to this application example: ZendExtended_Controller_Action extends zend_controller_Action )
applicationStorage\Applications\external\mobile\ (mobile external customer access application different workflow limited capabilities compared to full site version)
applicationStorage\Applications\internal\ (application grouping folder) (contains all internal company applications)
applicationStorage\Applications\internal\site\ (main internal application)
applicationStorage\Applications\internal\mobile\ (mobile access has different flow and limited abilities compared to main site version)
applicationStorage\Tests\ (contains PHP unit tests)
applicationStorage\Library\
applicationStorage\Library\Service\ (contains all business logic, services and servicelocator; these are completely decoupled from Zend framework and rely on models' interfaces)
applicationStorage\Library\Zend\ (Zend framework)
applicationStorage\Library\Models\ (doesn't know services but is linked to Zend framework for DB operations; contains model interfaces and model datamappers for all business objects; examples include Iorder/IorderMapper, Iworksheet/IWorksheetMapper, Icustomer/IcustomerMapper)
（注：Modules、Config、Layouts、ZendExtendedの各フォルダーは、各アプリケーションフォルダーで重複していますが、目的に必要ないため、省略しています。）
ライブラリの場合、これにはすべての「ユニバーサル」コードが含まれています。 Zendフレームワークはすべてのアプリケーションの中心にありますが、ビジネスロジックをZendフレームワークに依存しないものにしたいと考えました。すべてのモデルおよびマッパーインターフェースにはZend_Dbへのパブリック参照はありませんが、実際にはプライベートにラップされます。
私の希望は、ビジネスロジック（サービス）を非Zendフレームワーク環境（おそらく他のPHPフレームワーク））。
ServiceLocatorを使用し、各アプリケーションのbootstrap内に必要なサービスを登録することで、リクエストとアクセスするアプリケーションに応じて、同じサービスの異なるバージョンを使用できます。
例：すべての外部アプリケーションには、service_auth_External実装のservice_auth_Interfaceが登録されます。
Service_Auth_Internalがservice_auth_Interface Service_Locator :: getService（ 'Auth'）を実装する内部アプリケーションと同じです。
私はこれでいくつかの可能な問題を見逃しているのではないかと心配しています。
私が半分考えているのは、すべてのエクスターナルのconfig.iniファイルであり、次に、グローバルな外部config.iniをオーバーライドまたは追加する個別のアプリケーションconfig.iniです。
誰かが何か提案があれば、私は非常に感謝しています。
個別のアプリケーション内でAJAX=関数にコンテキスト切り替えを使用しましたが、外部と内部の両方がそれらのために作成されたWebサービスを取得する可能性が高いです。繰り返しますが、これらは承認のために分離され、異なる利用可能なサービス。
\applicationstorage\Applications\internal\webservice
\applicationstorage\Applications\external\webservice
最終的に、一部のコードはアプリケーションの「ビジネスロジック」に固有であり、一部は「ライブラリコード」です。たとえば、フォーム入力を検証するものは一般に「ライブラリ」と見なすことができますが、特定の月にクライアントXが利用できるオファーを計算するのに役立つものは明らかに「ビジネスロジック」です。
これはバージョン管理の問題であり、この特定の猫のスキンを作成する方法はたくさんあります。 Maven（およびある程度Phing/Ant）のようなツールは、さまざまなdisparateソース-ある種の外部構成ファイル（通常はXML）に基づいてアプリケーションをアセンブルするように構築されています。つまり、必要に応じてlibraryコードの個別のリポジトリを維持し、アプリケーションXにインポートできます。
ホストを制御できる場合は、ライブラリをインクルードパスに移動することを検討し、それを個別の長期プロジェクトとして維持できます。