如何使用 CMMI 项目模板通过 TFS 跟踪域实体？
我的企业即将启动一个有些复杂的项目，我们可能会在其中使用 业务层的领域驱动设计。该项目将使用 Visual Studio 2010 进行开发，并使用 CMMI 5.0 团队项目模板通过 TFS 2010 进行管理。
我认为使用 TFS 工作项来跟踪和管理业务层中域实体和值对象的定义是一个好主意。然而，CMMI 项目模板似乎没有任何合适的工作项。我有以下解决方法：
使用需求工作项， 修改它，以便 需求类型字段还有一个可能的值，例如“Domain 实体”。
向项目添加新工作项 模板。
放弃并且不使用 TFS 来管理域实体，而是在单独的文档上跟踪它们。
我的问题是：您认为最合适的方法是什么？并且，过去是否有人做过类似的事情（使用 TFS 工作项管理域实体）？
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:
Use the Requirements work item,
modifying it so that the
Requirement type field has one more possible value, such as "Domain
Entity".Add a new work item to the project
template.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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
注意：我以前没有听说过有人尝试过这个，所以 YMMV :-)
我倾向于添加一个新的工作项类型，并将需求链接到域实体，以便您可以看到哪些需求影响哪些实体，以及您还可以将域实体链接到其他实体。
我还倾向于包含有关工作项的其他信息，例如上下文、聚合根等，以便实体工作项有更多的信息。
使用 TFS 工作项执行此操作可以为您提供历史记录和跟踪，这很可能值得这样做，但是我还确保我也有从实体工作项到域 doco 的链接，假设它存储在类似项目门户或其他存储库。
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.