关于将数据库视为API的评论是正确的。虽然实现方式非常不同——从源代码构建和部署数据库需要特殊工具，而不仅仅是编译器+xcopy——但就概念上而言，您的情况与共享公共实用程序库的团队并没有什么不同。
幸运的是，这是一个经过充分研究的话题。此外，没有任何与TFS有关的特别之处；您可以阅读任何具有强大分支和合并功能的源代码控制系统的文档，目前大多数系统都具备这些功能。例如《实用Perforce》、《Red Bean》书籍（SVN）、Eric Sink的博客（Vault）等都具有良好的见解。我特别喜欢Laura Wingerd关于代码行的演示文稿。当然，您也应该阅读最新的TFS指南。
在StackOverflow上，将这些概念付诸实践的问题也已经出现了多次。对于TFS用户来说，这个Team Foundation Server Source Control Structure是最好的总结。它包含了最重要的行业原则...
- 所有分支都是自包含的。分支之间或分支与固定（非分支）位置之间不允许有依赖关系。
- 分支内的相对路径不变
- 晋升模型被明确定义，并适用于所有工程艺术品：开发->集成->生产（使用它们的术语来表示主要代码行；许多其他常用的，通常归结为相同的核心思想）
- 1个集成分支（也称为“树干”或“主干”），连接树的稳定和不稳定侧。不允许点对点合并。
- 根据需要隔离团队/功能/重构的程度，可以有可变数量的Dev分支
- 可变数量的Release分支，取决于热修复的频率、任何版本的重叠以及审核要求的严格程度
- 如果您选择签入次要资源（如文档、第三方二进制文件、编译器等），它们应该位于分支结构内。请参阅规则#1。
...连同一些TFS特定的怪癖...
- 不要使用工作区映射来规避共享文件的问题。（我不知道谁最初写了这个“建议”——幸运的是，在最新的P&P修订版中它已经不再出现）
- 不要将分支/合并到现有分支层次结构的子目录中。 （同样，自TFS推出以来一直遵循的一些“建议”，即使我还没有遇到过一个人是因为他们遵循了这个建议而感到高兴）
- 不要使用默认的TeamBuildTypes文件夹；像所有代码一样，您的构建脚本应该遵循上述的1-3要点。
（坦白说，虽然那里的回答已经变得有点太详细了。即使你有数十个或数百个分支，也没有必要将它们嵌套得像修改后的问题那样深入源码树中。对于那些初次接触大规模源管理和/或路径空间分支管理的读者来说，有些分支尤其令人困惑，会掩盖主要的收获。如果你希望让你组织的每个人都遵守“路规”，如Wingerd所说，简单就是金色的。）
无论如何，我知道你并不是特别询问分支和合并，但是你设置源码树的方式直接影响您的整个软件流程。坦白地说，如果您在添加数据库项目时不遵循#1这样的规则，您的前端应用程序团队将永远无法独立运作。因此，您的第一个提议（在$/FrontOfficeDevelopment下显示的结构）比第二个更接近实际情况。但是您需要更进一步。将3个应用程序+数据库的文件夹向树深度移动一级。也就是说，给它们一个共同的父级——让我们称之为“Integration”，以匹配其他StackOverflow示例。如果您需要分支，现在可以通过分支此容器来进行一个自包含的操作；如果每个应用程序都是Team Project中的顶层文件夹，则会更加困难。不久之后，您的源代码树将看起来像“TFS Guidance II”图表中的理想状态...这并不是巧合：）
$/Everything
|- Integration
|- 3rdPartyAssemblies
|- Database
|- OnlineOrders
|- Code
|- Tests*
|- ReportingSuite
|- Code
|- Tests
|- TeamBuildTypes
|- TfsBuild.proj
|- QuickBuild.targets
|- FullBuild.targets
|- FullBuildAndTest.targets
|- TradeManagement
|- Code
|- Tests
|- Development
|- 3rdPartyAssemblies
|- Database
|- etc
|- Release
|- 3rdPartyAssemblies
|- Database
|- etc
将测试按应用程序分开，如上所示，使得各个团队更容易在他们负责的部分上工作。例如，OnlineOrders 团队只需要下载 OnlineOrders 以及共享的部分，如第三方库和数据库。如果您的应用程序非常大或者有数十个/数百个应用程序，这是非常方便的。但是，将所有测试放在分支内的一个顶级 Tests 文件夹中也同样有效，如下所示：
|- Integration
|- Database
|- OnlineOrders
|- ...
|- Tests
|- Database
|- OnlineOrders
|- ...
这样做使得一次运行整套测试更加方便，并减少了树的深度/复杂度。缺点是在日常工作中你需要更频繁地在树中导航。或许更令人困扰的是，这需要你手动维护一个平行的结构。随着时间的推移，添加/删除项目、代码重构、部门重组、外包等等很多事情都可能会改变主代码文件夹的布局。如果不更新 Tests 以匹配这些变化，至少会让 QA 的人感到困惑，还有很大的机会出现测试自动化失效。
你还提出了将公司的工作划分为团队项目的问题。好消息是，这个决定完全与你选择的分支/合并流程无关。与构建、报告、SharePoint 神器和（在某种程度上）工作项紧密耦合的团队项目概念不同，TFS 源代码控制系统只是一个跨越它们所有的大树。我在图表中使用了“Everything”项目，因为这样比较容易绘制——而且我自己也确实偏爱这种策略——但实际上这并不重要。
然而，将我们到目前为止了解到的内容与 TFS 的“团队项目”概念结合起来需要额外的思考。我承认，从产品的粗略外观上很难看出“团队项目”到底是干什么的。可以说它们被设计成是非常大的容器。让我们举一些熟悉的例子。Windows 和 Office 绝对应该是单独的团队项目——它们按独立的发布时间表开发，使用非常不同的工程实践，运行定制的错误报告和报告工作流，完全不兼容的构建系统等等。然而，即使 NTFS 团队和 MSPaint 团队的实际工作从未重叠过，也没有理由将它们分开成单独的团队项目；除非下一个发布里程碑也带来了重大的流程变化，否则 Windows 7 SP1 和 Windows 8 的开发也不应该被分开。
与分支一样，我认为简单就是金色的。一旦有了多个团队项目，许多曾经平凡无奇的任务突然变得棘手起来。假设你在一个主要由另一个团队开发的数据库存储过程中发现了一个 bug。你会在你的团队项目中打开这个 bug（以确保它被解决并返回给你进行 QA 签名）、在另一个团队的团队项目中打开它（因为他们将编写修复程序），还是在一个专门的 DB-only 团队项目中？平均开发人员需要搜索多少个活动工作项呢？这只是我想到的第一个场景；还有很多功能在不同团队项目之间无法转换。不幸的是，也有一些功能要求你分开做。如果团队 #1 想使用即时合并，但团队 #2 的开发流程依赖于独占锁定，那在单个团队项目中就不支持。
我已经多次使用了“进程”这个词。这确实是关键所在。一旦你理解了 TFS过程模板 的概念，团队项目就会变得更加清晰易懂。在这里 这篇旧博客中，我深入探讨了这个想法，并提出了一个方便的经验法则：每个进程模板创建一个团队项目。当然也有例外；并非所有TFS功能都可以通过模板来控制。更多详细信息请参见促使我写这篇文章的白皮书——里面包含一张表格，详细说明了单个团队项目内部/之间支持/不支持的内容。我的猜测是像你们这样的小企业不需要做太多妥协就可以适应单个团队项目的模式。
