具有以下不同项目的网络核心解决方案，
- API-包含客户端应用程序正在调用的控制器
- 应用程序-具有业务逻辑
- 数据-DbContext
- 域-具有数据项目中表的类
- 基础设施-生成令牌
我的问题是，当我进入生产环境时，是否可以在不同的服务器中使用API，在不同的服务中使用应用程序、数据、域和基础结构？这是最好的做法吗？
我们非常感谢任何帮助、想法和建议。
感谢
第一个问题的答案是这是可能的。理解这一点的一种方法是认识到UI和API之间的接口类似于API和后端之间提出的接口。与UI通常位于与API不同的服务器上相同，API可能位于与相关业务逻辑不同的服务器。只要每个组件之间的接口在其范围内被理解和使用，生产应用程序的不同部分就没有理由不在不同的服务器上。这背后的原则通常被称为"关注点分离"。
- UI-了解如何从API"接收"数据并将数据"发送"给用户
- API-了解如何从UI"接收"数据并将数据"发送"到业务逻辑处理
- 应用程序-了解如何从API"接收"数据并将数据"发送"到数据存储
这个问题的第二部分类似于微服务还是单片架构之间的问题。在微服务架构中，每个服务都应该很好地处理一个操作，其他组件应该通过明确定义的接口与之通信。这导致代码和部署更容易遵循和扩展，而代价是标准化和维护与网络通信相关的接口和问题。
如果有一个体系结构在各个方面都是最好的，那么每个人都会使用它，就没有必要进行进一步的评估。话虽如此，在我看来，划分服务的好处与存在的唯一服务的数量成正比。因此，只拆分为API和后端服务器是不值得的。随着"分离关注点"数量的增加(例如：许多后端组件(，这些好处开始变得更有价值。
可能值得进一步将后端划分为许多不同的服务。例如：应用业务逻辑可以分为类型1、类型2和类型3。