Best Way to Group Entities in a Project #5839

New Issue

admin · 2026-01-22T15:19:21+01:00

admin commented

2026-01-22 15:19:21 +01:00

Originally created by @ragboyjr on GitHub (Jan 10, 2018).

Hey guys, I'm very big fan of doctrine and the amazing work you guys have produced in the project. I wanted to create a discussion regarding best practices on how to group and where to store entities in your code (not like in the database, but where to put the files).

The symfony examples all show entities within the Entity namespace where your entire projects entity domain is one folder. I've never been terribly fond of that because I feel like it needlessly separates my domain logic across folders.

I typically opt for yaml mapping and put my entities in whatever module they fit in. The symfony way would be:

src/Entities/
  User.php
  Product.php
  Category.php
  Order.php
  Shipment.php

but I've found structuring my code like the following helped organize my code better:

src/Model/
  User/User.php
  Catalog/
    Product.php
    Category.php
  Order/
    Order.php
    Shipment.php

Where each sub folder in Model acts like a module, and each module would contain any services/interfaces related to the User aspect of my system. Keeping the entities closer to their features tended to feel better to me, but I could be totally wrong.

I was curious if anyone has any pro/cons for either method or has maybe even better directory structures.

If this leads to a good discussion, i wouldn't mind condensing what we talk about into a doc page for folder-structure in the cookbook or something.

Originally created by @ragboyjr on GitHub (Jan 10, 2018). Hey guys, I'm very big fan of doctrine and the amazing work you guys have produced in the project. I wanted to create a discussion regarding best practices on how to group and where to store entities in your code (not like in the database, but where to put the files). The symfony examples all show entities within the `Entity` namespace where your entire projects entity domain is one folder. I've never been terribly fond of that because I feel like it needlessly separates my domain logic across folders. I typically opt for yaml mapping and put my entities in whatever module they fit in. The symfony way would be: ``` src/Entities/ User.php Product.php Category.php Order.php Shipment.php ``` but I've found structuring my code like the following helped organize my code better: ``` src/Model/ User/User.php Catalog/ Product.php Category.php Order/ Order.php Shipment.php ``` Where each sub folder in Model acts like a module, and each module would contain any services/interfaces related to the User aspect of my system. Keeping the entities closer to their features tended to *feel* better to me, but I could be totally wrong. I was curious if anyone has any pro/cons for either method or has maybe even better directory structures. If this leads to a good discussion, i wouldn't mind condensing what we talk about into a doc page for folder-structure in the cookbook or something.

admin closed this issue

2026-01-22 15:19:21 +01:00

admin commented

2026-01-22 15:19:21 +01:00

@Ocramius commented on GitHub (Jan 10, 2018):

I suggest reading through http://mnapoli.fr/organizing-code-into-domain-modules/

@Ocramius commented on GitHub (Jan 10, 2018): I suggest reading through http://mnapoli.fr/organizing-code-into-domain-modules/

admin commented

2026-01-22 15:19:22 +01:00

@ragboyjr commented on GitHub (Jan 10, 2018):

Lol, @Ocramius this freaking rocks, did you just have this on bookmark or something?

@ragboyjr commented on GitHub (Jan 10, 2018): Lol, @Ocramius this freaking rocks, did you just have this on bookmark or something?

admin commented

2026-01-22 15:19:23 +01:00

@Ocramius commented on GitHub (Jan 10, 2018):

No, @mnapoli posted it a few days ago, and it matches the topic :-)

@Ocramius commented on GitHub (Jan 10, 2018): No, @mnapoli posted it a few days ago, and it matches the topic :-)

admin commented

2026-01-22 15:19:24 +01:00

@ragboyjr commented on GitHub (Jan 10, 2018):

Yes, it does quite well. This was the one thing I've never loved about the skeleton structures of frameworks like symfony/laravel, they group all of their code by type vs feature. But i guess it'd be a bit harder to have a skeleton project off of feature vs type.

Anyways, what do you think about including some information from that article in a cookbook or doc page in the doctrine ORM?

@ragboyjr commented on GitHub (Jan 10, 2018): Yes, it does quite well. This was the one thing I've never loved about the skeleton structures of frameworks like symfony/laravel, they group all of their code by type vs feature. But i guess it'd be a bit harder to have a skeleton project off of feature vs type. Anyways, what do you think about including some information from that article in a cookbook or doc page in the doctrine ORM?

admin commented

2026-01-22 15:19:29 +01:00

@Ocramius commented on GitHub (Jan 10, 2018):

Not sure about it - it is true that the project is getting more opinionated about which approach is to be taken, but the location of entities makes no difference to the ORM.

You may also want to check discussion going on in https://github.com/doctrine/doctrine2/pull/6902

@Ocramius commented on GitHub (Jan 10, 2018): Not sure about it - it is true that the project is getting more opinionated about which approach is to be taken, but the location of entities makes no difference to the ORM. You may also want to check discussion going on in https://github.com/doctrine/doctrine2/pull/6902

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#5839