@syntaxseed You're highlighting why that directory structure is problematic and limiting. 🙂
You could have a Model directory for data model stuff, which somewhat overlaps with entities. If it's an enum used by a repository, you can stick it in the repositories directory.
I am not aware of any real standard at the moment.
@Crell@syntaxseed Agreed. Organizing things by what they do isn't optimal. Imagine to organize a house like that: a room for things that throws water, like kitchen sink and the shower, and another for things that emit warm, like fireplace and stove. If you organize thing semantically, you can have a folder with some views, some controllers, enums, value objects, etc, all related to the same conceptual part of the thing. Another folder with other views, other controllers, etc.
@syntaxseed depends on the amount of usages, the amount of classes in general and so on.
Also depends on if Entities are strictly belonging to an ORM, or are open for all kind of data holding objects. But generally I would see enums there.
We got more flexible caused by the amount of classes we have, so if the usage is limited, we would put it besides the Service introducing it.
like, MyBenderService and MyBenderServiceStatusEnum, MyBenderServiceBenderValueObject.
@syntaxseed of course we have a lot of sub directories in services for all the different domain parts 😅
only think I would strongly advice against is using a directory or namespace called objects.
Its to ambiguous, and close to the reserved keyword "object"
Then better use ValueObjects, or some also like to use DTOs
@kniziol I like that idea but unfortunately none of my projects are organized by domain like that. But after your project gets to a certain size... you really do need to start organizing that way or it just becomes chaos. 😅
@syntaxseed If its part of an entity (eg PostType, used by entity Post) then its in src/Entity/Enum. Otherwise it's often in a subdirectory close to where it 'belongs' like a valueobject.
@syntaxseed@nanawel I just refactored a new project that was starting out with that same Symfony-style base namespace and it came out exactly with not so many first-level folders: I split by concern (it's a service to sent templates emails, so delivery, templates, admin...) , then subfolders are allowed to be "per kind" (controller, entity..), but not always.
I was very happy of how it came out, and this approach can solve your kibd of issue "naturally". I definitely suggest it.
@syntaxseed Honestly, not clue where to put them in that structure. Using a package like/DDD/hexagon structure for my projects so they naturally end up were they fit. In that structure, either each in their own dir under src/ or otherwise maybe with entities and services?
Add comment