我试图在.Net核心中开发微服务。计划实施类似的项目结构
Frontend
Services
-Product
-Product.Api
-Product.Application
-Product.Domain
-Product.Infrastructure
-Basket
-Basket.Api
-Basket.Application
-Basket.Domain
-Basket.Infrastructure
-Order
-Order.Api
-Order.Application
-Order.Domain
-Order.Infrastructure
在上述项目结构中，服务文件夹下目前有三个模块(产品、篮子和订单(。稍后将添加许多模块。
每个模块有4个项目，分别是Api、Application、Domain和Infrastructure。如果增加更多的模块增加类库和web项目的数量。由于我的硬件不够，这将降低Visual studio项目的加载、编译和运行时间。
请推荐其他模式来优化微服务中的项目数量？
如果类库的数量是体系结构性能的决定因素，那么也许是时候将模块聚合到同一个模块中了。
如果绝对有必要继续使用微服务架构和大量模块，你应该考虑投资更强大的硬件。
开发软件通常需要大量ram来容纳本地运行堆栈的所有进程。
另一种方法是尝试在Azure等云平台上进行开发，并使用相应的工具针对云实例甚至在GitHub代码空间中进行调试。
如果Product、Basket和Order是不同的微服务，那么它们应该在不同的Visual Studio解决方案中。每个解决方案都是小型且独立的，无论你有多少微服务，它们都会快速加载和工作。
如果Product、Basket和Order是同一个微服务的一部分，并且您计划添加更多的模块，那么您的微服务设计可能是错误的，因为单个微服务似乎有太多的责任。在这种情况下，解决方案是限制每个微服务的责任，这样它们就不会发展到巨大的规模。
如果你正在构建的是一个模块化的整体(一个单独的可部署单元，但代码以模块形式组织(，那么解决方案就有点不同了。如果它是一个单独的开发应用程序，那么您可能不需要将模块拆分到单独的项目中。例如，整个API可以是一个单独的项目，每个模块都在不同的文件夹中。如果有许多开发人员和团队在编写源代码，那么您可能需要为每个模块创建一个单独的解决方案，这样每个团队都可以编写自己的代码。
Like@abo说：如果影响应用程序性能的程序集数量考虑每个模块一个程序集。
如果每个模块有多个程序集的驱动程序是依赖项管理的，那么可以考虑使用其他工具，如https://github.com/realvizu/NsDepCop这允许您在没有编译器帮助的情况下强制执行体系结构/依赖性规则。
好吧，我有一些关于你正在制作的架构的笔记。如果你做对了，回报之一将是对硬件的影响较小。
注意#1:制作一个内核模块，它具有所有通用功能的抽象。(其他微服务并参考(。类似于基本存储库、消息队列基本处理程序、命令/命令处理程序。如果你想断开一个模块与内核的连接，你可以这样做，并在该模块中单独添加你自己的抽象(简单就是终极的复杂(。
注意#2:并不是每个模块都需要有与u相同的项目或层，例如：一般来说，Basket不需要基础设施。它所做的一切就是告诉订单模块该用户是否有任何正在进行或挂起的订单。
注意#3：微服务因需要高端服务器来处理大量节点/应用程序而臭名昭著。
最后，我有一个很棒的蓝图供你们学习和遵循。它恰好涵盖了你所追求的同一个案例。
这是链接