Myself and two colleagues had a very interesting discussion about the structure of our domain projects. Originally we had this sort of folder structure within our domain projects:
This wasn't awful but it also wasn't perfect, after a bit of work we decided to restructure like this:
Its difficult not to prefer this folder structure as it keeps things that are related together in the folder structure and emphasizes key abstractions/classes (such as Customer here).
Unfortunately we've had to create "Component Parts" folders that, we plan, will contain any classes that are not key aggregate roots. The top level "Component Parts" folder has very reusable classes, but the one within "Customer" is for classes that relate just to the "Customer" aggregate(s).
This idea of a "component part" may seem odd but it does help show that whilst CustomerIdentifier is important it is not in any way as key as Customer.
The discussion also emphasized that it is impossible to get a project structure that we are completely happy with, trying to impose a single hierarchy on a domain model is just so difficult to do cleanly.
Its also worth noting that the small size of this example means it is not a good example, but we have already started giving this folder structure a go and so will hopefully find out just how well it works.