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