Question

My enterprise is about to start a somewhat complex project in which we will probably use Domain Driven Design for the business layer. The project will be developed using Visual Studio 2010, and managed via TFS 2010 using the CMMI 5.0 team project template.

I think that it would be a good idea to use TFS work items to track and manage the definition of the domain entities and the value objects in the business layer. However is seems that the CMMI project template does not have any suitable work item for this. I have tought of the following workarounds:

1. Use the Requirements work item,
   modifying it so that the
   Requirement type field has one more possible value, such as “Domain
   Entity”.

2. Add a new work item to the project
   template.

3. Give up and do not use TFS to manage domain entities, tracking them on a separate document instead.

My questions are: What would be in your opinion the most appropriate approach? And, has anyone done something similar (managing domain entities using TFS work items) in the past?

Answer 1

Note: I’ve not heard of anyone trying this before, so YMMV 🙂

I’d be inclined to add a new work item type, and link requirements to the domain entities so that you can see which requirements impact which entities, and you can also link domain entities to other entities.

I’d also be inclined to include other informaiton on the work item such as context, aggregate root, etc so that the entity work item has a little more information around it.

Doing it with TFS work items gives you history and tracking, which may well make it may be worth doing, however I’d also ensure I have links from the entity work items to the domain doco as well, assuming it’s stored in something like the project portal or other repository.