過去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を使用して、各アプリケーションのブートストラップ内に必要なサービスを登録すると、リクエストとアクセスするアプリケーションに応じて、同じサービスの異なるバージョンを使用できます。
例：すべての外部アプリケーションには、service_auth_External実装service_auth_Interfaceが登録されています。
Service_Auth_Internalがservice_auth_Interface Service_Locator :: getService（ 'Auth'）を実装するService_Auth_Internalの内部アプリケーションと同じです。
私はこれに関していくつかの起こり得る問題を見逃しているのではないかと心配しています。
私が半ば考えているのは、すべての外部のconfig.iniファイルであり、次に、グローバルな外部config.iniをオーバーライドまたは追加する別のアプリケーションconfig.iniです。
誰かが何か提案があれば私は非常に感謝します。
個々のアプリケーション内でAJAX機能にコンテキスト切り替えを使用しましたが、外部と内部の両方がそれらのために作成されたWebサービスを取得する大きな可能性があります。繰り返しになりますが、これらは承認とさまざまな利用可能なサービスにより分離されます。
\applicationstorage\Applications\internal\webservice
\applicationstorage\Applications\external\webservice