我正在尝试为我的测试微服务理解并创建最佳方法。 微服务的结构如下：
应用层协调任务并委托工作。它具有命令，事件处理程序，验证等...
基础结构层处理数据和其他事物。这是存储库的实现，数据库上下文，...
我需要引入一个服务（我们将其称为userService），该服务应从MyTestService.API中调用。该服务将使用存储库以获取数据。
该服务应存储在哪里？
在基础架构层？如果是这样，如果我已经在这里使用了公开的存储库，这有什么用？
在域层中？域层不应该了解外部事物。
这使我的应用程序层成为唯一选择。由于这是一个Web API项目，因此我将该服务放在Service文件夹中。
您将如何构建微服务文件夹结构？
答案 0 :(得分：1)
如何构造基于微服务的项目有很多可能性。我建议如下：
每个微服务都在单独的解决方案中 将每个微服务放在单独的解决方案中有多个好处。其中一些是：独立的微服务（或域）团队，如果需要，能够为每个微服务使用不同的技术，较小的代码库等等。
MyTestService.Infrastructure 将基础结构代码提取到一个单独的项目中，并从中创建一个库（nuget包）。如果您的基础结构包含用于数据库访问，缓存交互，身份验证和类似通用功能的代码，则可以创建一个库并将其在多个微服务中重用。在这种情况下，您的基础架构将是域无关的，并且只专注于为多个微服务提供通用解决方案。
您的微服务可能会在该解决方案中包含项目：
MyTestService.Domain 。其中应包含您针对某个特定微服务及其域的所有域/业务逻辑。在这里，您应该放置与特定微服务相关的业务逻辑代码，例如验证，命令和事件的处理程序等。该层将使用基础结构作为共享库，以便执行数据库访问，缓存交互等。请记住，每个微服务将有其自己的Domain项目。如果使用DDD（域驱动设计），则可以将该Domain项目分成多个。您可以在线进行快速搜索。有很多示例说明了如何构建DDD项目。
MyTestService.API 。这将是带有Rest api端点的WebApi项目。在这里，您将拥有自己的Controllers，ApiModels以及用于引导项目所需的东西，例如Dependency Injection组合根和类似的东西。您将在该项目的多个解决方案中使用的东西也可以提取到基础结构中，并在多个微服务API（WebApi）项目中重复使用。该项目将成为您尝试直接调用您的微服务（例如使用http）的每个人的微服务入口。从这里，您可以将调用分配到.Domain项目中的特定代码。
MyTestService.Domain.Test和MyTestService.API.Test 。如果编写测试，则可以添加的另一项是MyTestService.Domain.Test和/或MyTestService.API.Test。在这里，您可以对两个项目进行单元和集成测试。同样，您可以将一些测试设置和通用测试基础结构放入基础结构库中。
示例
假设您有2个微服务Users和Orders微服务。您将有2个解决方案（每个微服务一个）和第三个用于内部结构的解决方案：
解决方案用户微服务。这将具有以下项目：
解决方案订购微服务。这将具有以下项目：
基础设施
您的微服务将使用这些nuget包重用数据访问和测试基础结构之类的通用逻辑，以避免重复，并且您的微服务将只关注业务逻辑，而不关注基础结构相关的事物。在编写新的微服务时，您不必在每个服务中重复基础架构代码，而您可以专注于域。随着项目的发展，您会在基础结构库中添加更多常见和新事物。
回到您的问题：
我需要引入一项服务（我们将其称为userService） 应该从MyTestService.API调用。该服务将使用 存储库以获取数据。
该服务应存储在哪里？
我不太确定您的意思，但让我尝试回答。 如果您的UserService应该是另一个服务的一部分，那么您应该重新考虑将其放入自己的微服务中。 如果要从被调用的微服务中调用其他一些微服务，并且您想知道此调用应该在哪里进行。我会在您的.Domain项目中说。为什么？因为它与其他微服务通信以执行某些业务操作，仍然属于您的域。就像“为了下订单我需要用户数据”。即使它正在调用另一个微服务，这仍然是订单微服务业务运营的一部分。现在，对其他微服务的调用及其在技术上的完成方式，您可以在一个基础结构库中拥有一个通用的基础结构逻辑。因为大多数微服务都需要从另一微服务中调用一个微服务，或者使用它们之间的某种同步或异步通信，所以您应该将此公共部分提取到基础结构代码中。