Symfony 4: How to organize folder structure (namely, your business logic)

Question

In the Symfony Best Practices is advised to not use bundles to organize business logic.

The bundles should be used only when the code in them is meant to be reused as-is in other applications:

But a bundle is meant to be something that can be reused as a stand-alone piece of software. If UserBundle cannot be used "as is" in other Symfony apps, then it shouldn't be its own bundle.

So, as I'm upgrading my app from Symfony 3.3 to Symfony 4, I think this is the right time to reorganize my code.

At the moment I have followed the "bundled-structure":

- src    - AppBundle       - Controller       - Entity       - Repository       - Resources       - ...    - MyNamespace       - Bundle           - BundleTodo               - Controller               - Entity               - Repository               - Resources               - ...           - BundleCatalog               - Controller               - Entity               - Repository               - Resources               - ...           - BundleCart               - Controller               - Entity               - Repository               - Resources               - ...           - ... 

Now, with the new directory structure, how should have I to organize my code?

I'd like to organize it this way:

-src    - Core       - Controller       - Entity       - Repository       - ..    - Todos       - Controller       - Entity       - Repository       - ..    - Catalog       - Controller       - Entity       - Repository       - ..    - Cart       - Controller       - Entity       - Repository       - ... 

But, is this correct? Is there any problem with the expected folder structure of Symfony 4 and Flex?

Or is better something like this:

-src    - Controller        - Core        - Todos        - Catalog        - Cart        - ...    - Entity        - Core        - Todos        - Catalog        - Cart        - ...    - Repository        - Core        - Todos        - Catalog        - Cart        - ...    - ... 

The same applies also to other root folders as described in the project directory structure (about how to override it).

Are there any rules or constraints that I have to take into account deciding my new folder structure?

TRYING TO SOLVE THE PROBLEM

So, trying to solve the problem, I'm going deeper in the documentation and I will write here what I will find.

• Controllers: Use a fine grained configuration of controllers.
• Twig:
• Entity: Use orm.entity_managers.some_em.mappings.mapping_name

---

Answer 1

Conway's law:

organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.

You should design your directory structure around how you organize work.

If you or your colleagues work full-stack on per feature basis you should group your code per feature. It will make navigation and code discovery easier.

If you or your colleagues are well specialized on back-end, front-end, translations etc. you should organize your code around that. Directory structure on per function basis will support clear split of responsibilities.

Also, the depth should depend on how big do you foresee a project to be. If it will be a 5+ years effort of 5+ people, you should probably go with splitting both on per feature and per function with nesting, as mentioned, depending on work organization. If it will be a 3 month project for one person i.e. some simple internal tool you should probably go with more flat structure. I would also recommend sticking to defaults.

Additionally, I found this article informative: https://blog.nikolaposa.in.rs/2017/01/16/on-structuring-php-projects/