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
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.
@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 ;)