By type
/Controllers/Events/ModelsBy topic
/Comments/Posts/UsersBy topic, then type
/Comments
/Controllers/Events/Models/Posts
/Controllers/Events/Models/Users
/Controllers/Events/ModelsMixed
/Comments/Controllers/Events/Models/Posts/Users
@frankdejonge comes close to what we use these days, except for a slightly different naming convention. We call "infra" "Web" or "Http" to give a better understanding what that package deals with. And in case we need a CLI package, those classes will get placed in a "Cli" folder. In addition to that we place all classes in the src folder. I do not like the idea of having multiple src folders even though I get your intention ;)
It depends on the project for me, if it has a large enough scope then I would usually do something quite similar to @frankdejonge but if I was building a small microservice for example I would tend to go by type.
@frankdejonge Awesome, thanks for sharing. Your goal to keep framework dependencies separated from your domain code is interesting. On one hand this sounds really smart, while on the other hand I wonder how well this works out, practically. I wonder if this causes you to not use a bunch of helpful, built-in framework tooling, simply because you're trying to be framework agnostic. Consider if you want to use a Collection class, which the framework supplies. Do you use a framework agnostic collection library instead? Seems odd?
As for dropping the suffixes, I go back and forth. I don't suffix language types (interfaces, booleans, etc.), but I will use class types (events, controller, validator, etc). Otherwise I find it too difficult to find things, since often different classes can share the same name, even though they are different types.
"By topic, then type" would also be known as a modular structur. It's generally a good idea simply because if you design your solutions to be modular you'll be able to expand them easily, while keeping code organised. See things like Symfony's bundles for example.
By topic (sub-domain), entities in the sub-domain root folder, then by type
example with 2 topics, Shifts and Employees:
@shochdoerfer I'm still toying with the 1 dir 2 dirs X dirs setup. One thing I don't like is to have to group the domain in an arbitrary namespace. I often see the Web/Http namespacing, but then it comes with a "Domain" namespace too which pretty much always puts me off.
Even this is a really, really old gist, I'd still just wanted to share my thoughts on it, which I wrote a blog post about it: https://stefanbauer.me/articles/an-alternative-way-to-organize-the-laravel-directory-structure - I think it's basically what @frankdejonge is doing. Do it for several years now and still happy with it – at least if we're talking about larger projects.
@reinink: sure thing.
This would be the basic setup. Controllers are framework things, views would optionally reside here too. To me
eventsare explicitly part of the domain. The domain emits and responds to them. This is one of the reasons I created league/events so you can have a domain focused lightweight events system. This also creates a nice separation between domain events and infra events, which both have valid reasons to exist. The same goes for commands, in symfony and laravel a "command" might be a console command, which is perfectly fine. However, in the domain it probably makes more sense to have commands as well but then let them be commandbus commands. Again, both are valid. I also try to steer clear from type suffixing in the domain. UserHasLoggedIn is a description of an event, thus event is implied. While theEventsuffix might be a common thing to see it's all about "naming patterns". So, let's apply the type suffing to something else in our domain. If we have a User and a user needs to be verified before the user can log in we may keep track of that with a boolean. If we were to create a class to represent this boolean, would we name it ActivationBoolean? Probably not. Anywho, I like to think about those kind of things as well, all in the context of scoping/grouping/naming things.