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