介绍
这也是我问过自己的事情。我一直有一个紧迫的问题与您的问题相似；
一个好的命名约定是什么？
我应该如何命名事物？他们应该进入文件夹还是项目？
在四处寻找之后，我怀疑答案是这并不重要。重要的是您的解决方案具有一些合理的架构，并且您尝试遵循良好的实践，例如SOLID。
我在这个主题上的 ASP.NET MVC 英雄是Jeffrey Palermo、Steve Smith和Jimmy Bogard。
洋葱架构
Jeffrey Palermo 讨论了旧想法的组合，但将它们结合在一起，并给它起了一个视觉上刺激的名字Onion Architecture（推荐阅读）。杰弗里展示了一个很好的方法来解决把东西放在哪里的问题。他解释说，在您的应用程序的中心（或顶部），您拥有Core。这一层是您应该放置接口的地方，例如IRepository和IService。
几乎所有接口都应该放在核心中，其他所有内容（其他项目）都可以引用核心。这样，在不知道实现细节的情况下，一切都知道应用程序的骨架结构。
尝试尽可能少地引用您的 UI 层（在合理范围内）。在我的一个应用程序中，我的 UI (MVC) 层仅引用了 Core。它需要的一切都通过Dependency Injection 注入其中。
Steve Smith 在MVC 解决方案最佳实践：解决方案问题的解决方案中讨论了洋葱架构和类似的想法
我的解决方案
在我的 MVC 解决方案中，我有一个典型的结构，如下所示：
- 我的项目.Core
- 我的项目.域
- MyProject.DependencyInjection
- MyProject.Infrastructure
- 我的项目网站
- 我的项目测试
核心包含我的接口。它通常分为服务、模型、域、存储库等文件夹。
域层仅引用核心并包含我的实现。它为核心中的领域抽象提供了很多具体的类。它处理大量的业务逻辑、处理、命令处理、管理器类、具体的服务实现等等。我认为它是一个相当内层，因此它尽可能少地引用。
DependencyInjection层包含我选择的DI 包/框架和实现细节。我认为它是外层；类似于 UI 或 Infrastructure，所以如果它引用很多也没关系。这一层没有必要成为一个单独的项目，很多人会告诉你不要这样做。没关系; 做适合您项目复杂性的事情。我喜欢我的 DI 是它自己的东西。它如此独立的好处是我可以用不同的框架替换 DI 框架，一切都会好起来的。没有图层引用 DI 项目。
基础设施层包含有关日志记录、电子邮件和数据访问的信息。它将包含我选择的ORM。这不是业务逻辑的东西，也不是 UI 的东西。这是我完成工作的解决方案的铁路。它在外层，但它只引用核心。
Web层是我的 MVC 项目，只引用了 Core 。
复杂性和最终想法
我在这里找到了类似问题的答案，但它们往往涉及比我在这里概述的更复杂的架构
这是一个很好的观点。记住问题的复杂性很重要。但不要被良好的解决方案所吓倒。我的解决方案和 Onion Architecture 不一定非常复杂，也不会真正使您的解决方案膨胀。他们只是把事情分开。
在Evolutionary Project Structure中，Jimmy Bogard 谈到事情过于复杂。如果我所说的似乎太复杂，请按照 Jimmy 的建议，将它们全部放在一个项目（您的 UI 层）中。没关系——只要它适合你。
请记住仅将我的解决方案作为一个想法 - 需要考虑的事情；我的方法是尝试遵循最好的明智建议，但我确信我只成功了这么多；我可以（而且必须）仍然改进。