Web应用程序体系结构：1或n API

背景： 我正在考虑web应用程序组织。我将分离前端（浏览器网站）和后端（API）：2个应用程序，2个存储库，2个托管。Front将为几乎所有内容调用API

所以，如果我有两个单独的域服务和我的API（例如：学习上下文和预订上下文），它们之间没有直接链接，我应该构建两个API（具有两个存储库、两个构建过程等）？为

n

需求构建

n

API是一种好做法还是一个“大”API？我说的是trafic的一个重要web应用程序

---

（我希望这个问题不会因为没有建设性而结束……我认为这是一个具体案例的真正问题，如果没有的话，很抱歉。还有一些关于架构的问题没有结束，所以我还有希望）

这一切都取决于您正在开发的应用程序、其业务需求、您的优先级等等。通常，您有几种选择：

• 只使用一个单片应用程序
• 只使用一个单一的应用程序，但在不同的模块/捆绑包/库之间解耦域模型
• 创建分布式体系结构（如面向服务的体系结构（SOA）或事件驱动的体系结构（EDA））

一个单片应用程序

这是在应用程序开始阶段开发应用程序最简单、最便宜的方法。您不必担心复杂的体系结构、复杂的部署和开发过程。如果周围没有太多的开发人员，它也会工作得更好

一旦应用程序成长起来，这个模型就开始出现问题。你不能单独部署模块，应用程序更容易受到反模式、意大利面条式代码/设计的影响（特别是当有很多人在使用它时）。QA过程需要越来越多的时间，这可能使其在CI基础上无法使用。引入持续集成/交付/部署等方法也要困难得多

在这种方法中，所有API都有一个回购/构建过程

一个单片应用程序，但解耦域模型

在这种方法中，您仍然有一个大平台，但您可以在第三方的基础上连接逻辑上独立的模块。例如，您可以提取一个模块并从中创建一个库

由于这一点，您可以为不同的库引入单独的流程（QA、dev），但您仍然必须同时部署整个应用程序。它还可以帮助您避免反模式，但在应用程序生命周期内可能很难保持跨库的向后兼容性

关于您的问题，通过这种方式，只要您将其域逻辑移动到单独的库中，每个“操作类型”都有单独的API、开发过程和存储库

分布式体系结构（SOA/EDA）

SOA有很多利润。您可以为每个服务引入完全不同的流程：开发、QA、部署。一次只能部署一个服务。您还可以为不同的目的使用不同的技术。QA过程变得更加可靠，因为它涉及更小的项目。您可以在服务之间使用版本通信（API），这使它们更加独立。此外，您具有更好的水平缩放能力

另一方面，高层体系结构的复杂性在增长。如果您的应用程序是数据驱动的（使用API消费数据的独立前端），则需要注意更多不同的组件：服务之间的身份验证/授权、安全性、服务发现、分布式事务等而且，特定的服务不需要相互沟通——这可能没有那么复杂（但这种假设在我看来是相当危险的，你迟早会需要沟通）

在这种方法中，您有单独的API，每个“操作类型”（我理解为单独的域模型/服务）都有单独的存储库和单独的流程

---

正如我在开头所写的，您选择的方式取决于应用程序及其需求。无论如何，回到您最初的问题，我的建议是尽可能地保持API的独立性。即使您有一个单片应用程序，您也应该能够分别对API进行版本设置，并保持其域逻辑的独立性。分离存储库和/或流程取决于您选择的方法（例如，在我前面提到的方法中）

如果我没有领会你的观点，请更详细地描述你期望得到的答案

---

最好的

谢谢你的回答！我为“独立域模型/服务”写了“操作类型”，你说得对（我将编辑我的问题）。这正是我想要的。我想我会选择第三个选项（我希望我可以分离部署过程），并非常小心组件的通信。