When working with SharePoint 2010 and the Visual Studio Tools for SharePoint, you can effectively structure your project how you like - this is because you can use folders to structure things logically, whereas in the past with SP2007 WSPBuilder projects you would typically mirror the 12 hive structure.
One option is to use folders for the different artifact types (e.g. content types, fields, list defs etc.). However, another choice might be to group things by functionality - it really comes down to what makes the most sense for you. In both cases, you can map things to whatever set of Features you like in the Feature Designer (or by editing the Feature files by hand).
Some considerations I use when structuring things, Features in particular:
- IMHO, code workflows should always go in a separate assembly (or assemblies) to your other artifacts, since if you need to upgrade the workflows, you'll probably want to version the assembly so you can create a new SPWorkflowAssociation. You may not want to version the assembly with all your other artifacts in at this time since that might break things (without further mitigation at least).
- Feature scope - some artifacts such as fields/content types are Site-scoped, whereas others such as list instances are Web-scoped. This often leads you to structure things in a certain way even when you actually wanted them in the same Feature.
- Feature dependencies are useful to e.g. have a Feature which deploys a list instance depend on the Feature which deploys the Site-scoped fields/content types
- SharePoint 2010 introduces Solution dependencies. Similarly these can be useful to have your WSPs depend on say, a core WSP which deploys supporting artifacts (though note you can retract a depended-on WSP, the check only happens at deployment time)
- SharePoint provisions artifacts in a Feature in the order they are declared. The Feature Designer has Up/Down buttons to move artifacts around (lots of people seem to be missing this), allowing you to ensure that where a Feature deploys some related artifacts, the provisioning happens in the correct sequence.
Part of it is understanding that a particular VS project's logical structure (folders) doesn't need to map too closely to the Features - you can map between the two however you want, subject to some of the constraints listed here.