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