Due to cross-dependencies in our domain model, we've grown accustomed to having all of our application's models in a single bundle. If we continue to do this, there's no logical reason to continue creating feature-specific bundles that hold their own services and controllers.
I propose the following directory structure, for an "Account" feature that will be integrated into MainBundle:
src/Application/MainBundle/
|- Account/
| |- Exception/
| | \- IdentityNotFoundException.php
| \- IdentityManager.php
|- Command/
| \- Account/
| |- CreateAccountCommand.php
| \- DeleteAccountCommand.php
|- Controller/
| \- AccountController.php
|- DependencyInjection/
| \- AccountExtension.php
|- Form
| \- Account
| |- ChangePasswordForm.php
| \- IdentityForm.php
|- Resources/
| |- config/
| |- routing/
| | \- account.yml
| \- account.xml
| \- views/
| \- Account/
| |- created.twig
| \- edit.twig
|- MainBundle.php
The general rule of thumb is that if your feature would take up a single file named after the feature, it's OK to put it in the parent folder (e.g. AccountController.php), but in most cases you'll nest it in a sub-folder, or prefix with something like "account_" (more appropriate for DIC/routing configs).
If your feature will have special classes (services, managers, exceptions, etc.), those can be organized under a top-level folder in the bundle. This is a departure from the convention of top-level Command, Controller, Form directories, but I believe those are standard enough to deserve first-class treatment.
I also propose that we keep only DIC configurations in Resources/config/ and move routing to a sub-folder for easy organization. XML is generally used for DIC configs, as YAML is used for routing, which makes both fairly easy to distinguish, but this prevents any confusion for edge cases and also avoids a cluttered bucket folder.
I'd rather not add a DIC extension for each feature. If additional config is necessary, it should flow under
main.config, similar to howapp.configworks: