Namespaceing convention

@Bounoable depends a little on your project, for example, if the App\Property namespace wouldn't be too crowded, I would use..

App\Property\Villa::class
App\Property\VillaType::class

But if Villa has many different properties and classes, I would make a namespace for everything Villa..

That's the thing. I also have a Style and a Location class for the villa class and the Location class also depends on another class.

So is this the best approach?

App\Property\Villa::class
App\Property\Villa\Type::class
App\Property\Villa\Style::class
App\Property\Villa\Location::class
App\Property\Villa\Location\Distance::class

Or this:

App\Property\Villa::class
App\Property\Type::class
App\Property\Style::class
App\Property\Location::class
App\Property\LocationDistance::class

I'm questioning if it's a good approach to put classes that "belong to" another class into a sub-namespace with the name of that class (Villa and Location in this example).

@Bounoable I don't know how many times I've started a project, gotten stuck on every single detail, to try do the best possible way and finally got so tired/bored that I never finished the project. So these days my general approach is to do the easiest thing, get it working and get it finished... if/when later I find the need to change it, I will change it.

I know this is a year old and closed, but a laracasts lesson on this would be super helpful. I find myself dumping everything in app, and then refactoring (painfully) classes into products inventory and everything you can imagine, and with polymorphic relations it gets uglier,

App\Products\ProductContract
App\Products\Product
App\Products\special\ProductA
App\Products\special\ProductB

etc...

Is there a good name spacing pattern as projects get too big to live in app easily? What do you do with the table names for 10 product types?