サブモジュールを試して実行するために、おそらく流れに逆らっていますが、おそらくその必要はありません。
モジュールを適切に作成した場合、それをロードすることはそれほど高価な操作ではありません。サービスマネージャーの要点は、これらすべてのサービスが遅延して作成されることです。したがって、呼び出し元のコードが特定のリクエストで特定のサービスを要求しない場合、そのサービスのクラスファイルが自動ロードされたり、オブジェクトがインスタンス化されたりすることはありません.
EventManager に大きく依存していて、モジュールが多数のリスナーをアタッチしている場合は、少し扱いが難しくなる可能性があります。ただし、いくつかのモジュール構成ディレクティブを設定し、条件付きでリスナーをアタッチすることで、おそらくこれを回避できます。
そうは言っても、モジュールを分割しようとするのはおそらく理にかなっています。したがって、FooBar および FooBaz モジュールを使用できます。
本当に、本当に、サブモジュールが必要な場合は、ModuleManager を掘り下げて、それを理解しようとすることができます。私は一度その道を少し下ったことがあります - そして気が散ってしまいました。私の場合、物理的なアイテムの発送を扱っていました。私のメインのフルフィルメントモジュールがロードされたすべてのサブモジュールを特定せずに反復できるように、一連の同様の出荷モジュール（Fulfillment\Courier\USPSModule、Fulfillment\Courier\FedExModuleなど）をロードするように構成できる「フルフィルメント」モジュールが必要でしたそれらのいずれかに関する知識。私の記憶が正しければ、それを行う最善の方法は、基本的に ZF2 が行うことをミラーリングすることでしたが、Fulfillment\Module クラス内で行いました。ただし、同じインターフェースをすべて実装する類似のサブモジュールのセットが必要でない限り、それを実行したい状況はあまり思いつきません。それらを特定の知識を持たないスーパーモジュールによって消費されることを望みます。エンドユーザーによるこれらのサブモジュールの実行時有効化/無効化(プラグインシステムのようなもの)について考えていたので、私もこれを見ました。
そうでない場合は、理にかなっている限り、FooBarModule、FooBazModule などに固執することをお勧めします。また、モジュールに大量のコードが含まれている場合でも、ServiceManager は、特定の要求の依存関係を満たすために必要なクラスのみをオートロード、解析、およびインスタンス化することを忘れないでください。