Structure for Organizing Team Projects

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.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

About Me

Consultant, Solution Architect, Developer.

Do note that this blog is very, very old. Please consider that before you follow any of the advice in here!


%d bloggers like this: