背景:
我正在考虑网络应用程序组织。我将前端(浏览器的网站)与后端(API)分开:2 个应用程序、2 个存储库、2 个托管。 Front 会为几乎所有的东西调用 API。
所以，如果我的 API 有两个独立的域服务(例如:学习上下文和预订上下文)，它们之间没有直接链接，我应该构建 2 个 API(带有 2 个存储库、2 个构建过程等)吗？构建 n 是一个好习惯吗？ n 的 API需要还是一个“大”API？我说的是一个有流量的大型网络应用程序。
(我希望这个问题不会因为没有 build 性而被关闭......我认为对于具体案例来说这是一个真正的问题，如果不是，很抱歉。This question 和其他一些关于架构的问题没有关闭，所以我的希望)
最佳答案
这完全取决于您正在处理的应用程序、它的业务需求、您拥有的优先级等等。通常你有几个选择:
一个单片应用程序
这是在开始阶段开发应用程序的最简单和最便宜的方法。您不必担心复杂的架构、复杂的部署和开发过程。如果周围没有很多开发人员，它也会更好地工作。
一旦应用程序成长起来，这种模式就会开始出现问题。您不能单独部署模块，该应用程序更容易受到反模式、意大利面条式代码/设计的影响(尤其是当很多人在使用它时)。 QA 过程需要越来越多的时间，这可能使其在 CI 基础上无法使用。引入持续集成/交付/部署等方法也困难得多。
在这种方法中，您的所有 API 都有一个 repo/build 过程，
一个单片应用程序，但解耦域模型
在这种方法中，您仍然拥有一个大平台，但您在第 3 方的基础上连接逻辑上独立的模块。例如，您可以提取一个模块并从中创建一个库。
多亏了这一点，您可以为不同的库引入单独的流程(QA、开发)，但您仍然必须一次部署整个应用程序。它还可以帮助您避免反模式，但可能很难在应用程序生命周期内保持跨库的向后兼容性。
关于您的问题，通过这种方式，只要您将其域逻辑移动到单独的库，您就可以为每种“操作类型”拥有单独的 API、开发流程和存储库。
分布式架构(SOA/EDA)
SOA 有很多利润。您可以为每个服务引入完全不同的流程:开发、QA、部署。您一次只能部署一项服务。您还可以将不同的技术用于不同的目的。 QA 过程变得更加可靠，因为它涉及较小的项目。您可以对服务之间的通信 (API) 进行版本控制，从而使它们更加独立。此外，您具有更好的水平扩展能力。
另一方面，高级架构的复杂性增加了。您需要注意更多不同的组件:服务之间的身份验证/授权、安全性、服务发现、分布式事务等。如果您的应用程序是数据驱动的(使用 API 来消费数据的单独前端)并且不需要特定服务相互交流 - 它可能没有那么复杂(但这样的假设是 IMO 相当冒险，你需要尽快或信函与他们交流)。
在这种方法中，您有单独的 API，每种“操作类型”都有单独的存储库和单独的进程(我理解为 ss 单独的域模型/服务)。
正如我在开头所写的那样，您选择的方式取决于应用程序及其需求。无论如何，回到你原来的问题，我的建议是尽可能地保持 API 分开。即使你有一个单一的应用程序，你也应该能够单独对 API 进行版本控制，并保持它们的域逻辑分开。分离存储库和/或进程取决于您选择的方法(例如，在我之前提到的这些方法中)。
如果我错过了您的观点，请更详细地描述您期望的答案。
最好的!
关于api - Web 应用程序架构 : 1 or n API，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/25907009/