When I was setting up our project layer based upon the Helix architecture principles for the project layer, this bit stood out to me:
Typically, in a single tenant solution there will only be a single module, namely the specific website or requirements that fits the needs of the tenant, and this will contain little or no pre-compiled code but instead consist of mark-up, styling, layout and templates of the item types in Sitecore which the editors can create (see Template types).
And for Habitat:
"The Common module paves the way for a multi-tenant implementation by defining some of the shared templates and settings between tenants."
So our current structure looks very similar:
- Project
- AbcWebsite
- Common
- QrsWebsite
- XyzWebsite
What I'm not sure is what the use case would be for another Common project for each website, as you've done.
Unless you have multiple multi-tenant implementations with their own shared code, I wouldn't expect you'd need another common project for each website. And if you do have multi-tenant implementations like that (such as if each multi-tenant instance is a different client/customer), I wonder if that should instead be a different Visual Studio solution, one for each client/multi-tenant instance.
This also means that if you don't have a multi-tenant solution, a Common project layer module wouldn't be required.
Sitecore.Foundation.Assets
,Sitecore.Foundation.Dictionary
,Sitecore.Foundation.FieldEditor
,Sitecore.Foundation.LocalDatasource
, andSitecore.Foundation.SitecoreExtensions
to be rather helpful. TeamCity complains about C# coding standard issues which bumps up our issue counts, but otherwise these are pretty solid.