I mostly implement a Domain Driven Design in my projects, depends on the size. So the base of my projects is build of some normal class library projects.
- Project.Core => Implements Core functionallity like Logging etc. pp
- Project.Repository => Implements the repositories. Mosttime I use some of them, one for each kind of data connection.
Then I split my subprojects into multiple Projects too. For example a Project named "Example" ;-)
- Project.Example => A SP Project implements all definitions for list and the UI.
- Project.Example.Models => All the Entities
- Project.Example.Repository => The Repository for the project
- Project.Example.Services => Implements the business logic.
So with this kind of architecture I have a very clean one. I know where I can find each class for each kind of action and I can keep my view clean from business logic. One other thing is to break down dependencies. So not every project needs all the other references. This architecture sometimes called "Onion architecture".
At the end I package all my core assemblies like the repository and the core into an other SharePoint Project to deploy them easily to the GAC.
At the moment I am working for a big project and my developers are putting all the stuff in one or two projects. So with every release all the other releases crashes too... its terrible. :D