我们是否应该将代码拆分为 API 和服务解决方案？ [已关闭]

Question

我们有一个带有数据库的 C# webapi 解决方案。我们所有的客户端（应用程序和 Web）都连接到此，并且我们已经使用 MediatR nuget 包实现了调解器模式。

现在我们对 API 的使用正在增长，我们使用：

• AWS API - 发送电子邮件（SES）、存储文档/图片（S3）
• HERE MAPS API - 检索地址信息
• OneSignal API - 发送推送通知
• E-经济 API - 发送发票和检索客户数据
• HubSpot API - 注册时在 hubspot 中创建客户
• Stripe API - 处理订阅/付款
• Stripe WebHook - 捕获从 Stripe 发送的事件
• 然后是我们为客户提供的 Rest API

所有这些都在我们的WebApi解决方案中使用 - 其中一些有不同的项目进行封装。

我们正在考虑将架构分为两个解决方案：WebApi 和服务解决方案。

WebApi 可以是域代码 + 我们的 REST API 和服务解决方案可以负责与外部服务的通信。该服务可以使用 RabbitMQ 进行 Stripe WebHook 和其他通信。 WebAPI 可以调用 Service 来实现我们需要的任何外部功能。 也许服务甚至可以知道 WebAPI 数据库，因此它有时可以从 stripe 接收 webhooks 事件，而不必使用 WebAPI 中的资源，或者服务可以调用 WebAPI 并且它将专门处理数据库层。如果我们选择走这条路，我们还没有决定。

但也许我们把事情过于复杂化了，只是为我们正在通信的每个外部 API 都有一个项目，而不是将其分成两个不同的解决方案。

您对如何拆分项目有什么建议吗？