我在一个 .net c# 应用程序中工作，其中包含 2 个用于客户端和服务器的解决方案。在服务器端，有 80 多个项目用于分离以下架构层，
此外，几乎每一层都有测试项目。现在，解决方案的构建时间需要 2 到 3 分钟，许多开发人员（包括我 :)）觉得我们需要解决这个问题。
因此，提出的解决方案是通过合并项目来减少项目数量。在我看来，最大限度地减少构建时间可能是一个很好的解决方案，我们可以实现我们想要的。
建议的解决方案是我们将我们的项目合并为 3 个区域，例如一个用于生产代码的库，一个用于测试代码的库，以及一个用于部署项目（WCF 主机等）的库，并通过分离命名空间在同一项目中逻辑划分层。
然而，我的担忧是
有没有其他方法来分层解决方案？
我想你应该把你的解决方案分成逻辑层。
作为你把助手放在哪里的一部分。在最低级别之一上为它制定解决方案。
例子
农场软件。您需要跟踪您的动物、蔬菜。您需要一个用于喂养动物的模块和一个用于向消费市场销售动物和蔬菜的模块。
这可以分为以下解决方案
后端
这些后端模块中的每一个都可以拥有自己的数据访问层、DTO、WCF 服务，......
此解决方案将仅包含业务逻辑、数据访问、...。并且可以有多个前端解决方案连接到这些后端解决方案。
前端
这对您的项目来说是一个很大的变化，这将产生影响。如果你不想改变它，请确保你认为这是真的。
多种解决方案将增加您的整体构建时间，并且每晚构建非常重要，这样每个开发人员都可以始终使用最新的二进制文件，而不必在他的本地计算机上构建所有解决方案。
请注意，您仍然可以在不同的解决方案中使用您的图层：
为了使这一切一起工作，不要弄乱二进制文件。您可以映射一个驱动器 IE X：您有一个文件夹二进制文件，每个解决方案都有一个文件夹。每个解决方案都复制构建后事件中的程序集。（编写此脚本，因此它适用于每台机器）
如果您有良好的网络基础设施，您也可以将其复制到服务器上。因此，当您在 TFS 中构建所有解决方案时，它可以将其复制到所有开发人员都可以访问的位置。
如果您在 TFS 中构建，请确保您的构建顺序正确，首先是最低层，最后是最高层。
但是当您拆分解决方案时，在解决方案中您可能不需要在每个解决方案中使用它们。
我最近读了一篇关于Onion Architecture的文章，也许你也可以看看。（它特定于 ASP.NET MVC）。
您还可以查看CQRS。
为什么有 80 多个项目，而您的应用程序只有 6 层？
您可能会回答说它们涵盖了大量的功能区域，但您首先需要将所有这些功能区域放在一个解决方案中吗？
我建议用项目反映建筑部门，用解决方案反映功能部门。不同的解决方案可以重用相同的项目。这样，您将为每个可重用的架构层创建一个项目，并拥有与功能区域一样多的领域项目。
我绝对不会合并这些项目......我认为你很快就会在每一层中得到意大利面条代码，因为开发人员会采取他们不应该采取的捷径（无论他们是否有意）。
我更倾向于将层分离成单独的解决方案......并使用二进制引用而不是跨层的项目引用。但是，这可能会对分支造成严重破坏，请小心。
我已经看到通过将项目构建到一个共同的地方来减少构建时间 - 显然这可以防止 VS 在不需要时重建项目 - 但我不知道这是否属实。
这里有一些想法：http: //blogs.microsoft.co.il/blogs/arik/archive/2011/05/17/speed-up-visual-studio-builds.aspx
最后......是完整构建的三分钟还是仅仅对一个项目进行单元测试？专注于最大的问题。如果单元测试需要很长时间，那么您就会遇到依赖关系问题。如果完整的解决方案需要很长时间，请获取构建服务器并专注于缩短单元测试开发时间。
希望有帮助
我过去处理类似问题的一种低影响方法是创建一系列解决方案文件，其中仅包含一个项目及其测试项目（可能还有项目的依赖项）。然后，给自己找一个像NCrunch这样的工具，并在这些解决方案中完成大部分编码，可能使用 TDD。这将为您提供闪电般的快速反馈循环，并且绝对符合分层、解耦方法的精神。当我过去这样做时，我发现我实际上每天最多只运行几次整个应用程序，而且我严重依赖 red-green-refactor，无论如何这都很好。
如果您愿意，您甚至不必对这些小的解决方案文件进行源代码控制——开发人员可以创建自己的文件，并且可以将它们丢弃。
当然，这绝不是灵丹妙药，也无法解决您想要运行应用程序时编译时间过长的问题，但它绝对可以帮助减少反馈时间，同时促进良好的设计/开发实践，而且它具有具有极低风险和快速设置的优势。