Coding Insomnia

As seen in previous posts, I have just started messing around with Team Foundation Server. My next area of concern is actually how to divide and organize all our current and future .NET solutions and services into Team Projects. As I wrote in a forum post on MSDN:

We are gradually moving to a more and more SOA-based approach where we have lots of rather fine-grained solutions, each of which contains something like 2-4 projects (DAC/BLL/WebService layers etc). All services use a common framework (for the most part using EnterpriseLibrary but with some custom extension) and there are also some dependencies between services. On top of this, we have a couple of web sites (internal and external) and some smart clients that consumes the above-mentioned services.

What would be a good way of organizing this? I guess we want a separate project for the common framework. Should we then have one project per service? Or should we try to group “related” services into larger projects? Or should we try to mimic our organization (i.e. try to map projects in MS Project to projects in TFS) which, for example, would mean creating a new project for every major release.

I did (finally) find some pointers on MSDN, but they basically say “you can structure it any way that seems to fit your needs” which isn’t really that helpful.
Hopefully, Brian Harry will keep his promise and blog about this soon. In the mean time, I’ll probably try a couple of different approaches.