我们有一个内部申请。随着时间的推移和请求新的应用程序，在彼此之间交换数据，交互变得绑定到数据库模式。数据库中的含义更改需要在其他任何位置进由于我们计划构建更多依赖于相同数据的应用程序，因此很快就会成为无法控制的混乱。
现在我想要在API背后抽象这种互动。目前我无法选择合适的工具。
交互有时可能很复杂，这意味着数据会发布到一个服务，如果操作已经完成，则应通知发件人。
另一个例子是某些数据没有来自其他服务的数据的上下文。假设[学校]有一项服务，[学生]有一项服务。因此，如果[学校]被删除或更改，[学生]需要立即得到通知，而不是当他来到[学校]时。
么？建议？ SOAP / REST /？
答案 0 :(得分：1)
我认为您不需要API。在我看来，你需要一个架构，它将你的数据库与域逻辑和应用程序的其他部分分离开来。这样的架构例如是clean architecture，onion architecture和hexagonal architecture（ports&adapters新名称）。它们共享相同的概念，你有一个域逻辑，它不依赖于任何框架，外部库，交付方法，数据存储解决方案等......这个域逻辑通过具有良好定义的接口的适配器与外部世界通信。如果您首先设计域逻辑的内部，以及适配器的接口，并且只是在外部组件之后，那么它被称为domain driven design（DDD）。
因此，例如，如果您想从MySQL迁移到MongoDB，您已经拥有了DataStorageInterface，您唯一需要的是编写实现此接口的MongoDBAdapter，并且迁移数据...
要设计适配器，您可以使用另外两个概念;命令和查询隔离（CQRS）和事件源（ES）。 CQRS用于将诸如REST，SOAP，web应用等交付方法连接到域逻辑。例如，您可以从REST API中引发CreateUserCommand。之后，域逻辑中的正确侦听器处理该命令，并且通过成功，它会引发域事件，如UserCreatedEvent。您的REST API可以侦听该事件并使用成功消息响应REST客户端。 UserCreatedEvent也可以由一个或多个存储适配器监听。因此，他们可以处理该事件并持久保存新用户。您不必仅使用单个数据库。例如，如果关系数据库通过特定类型的查询更快，那么您可以使用它，但如果noSQL数据库更适合该作业，那么您也可以使用它。因此，您可以根据需要为查询使用尽可能多的数据库，您唯一需要为它们编写存储适配器。例如，如果您的REST客户端想要检索特定用户的配置文件，那么它可以引发GetUserProfileByIdQuery，并且域逻辑可以向适配器询问可以为查询提供服务的数据库。之后，适配器可以将例如SQL查询发送到MySQL数据库并返回响应。通过ES，您可以将EventStorage添加到您的系统，该系统存储已提升的域事件。如果要将数据从一个查询数据库迁移到另一个查询数据库，这将非常有用。在这种情况下，您将为新数据库创建一个新的存储适配器，并以历史顺序将所有域事件从EventStorage重放到该适配器，以便它可以使用相关数据填充新数据库。总而言之，您不必编写复杂的迁移脚本......
在您的情况下，我认为您应该创建至少域事件，并使用事件源。这将完全将您的数据库与应用程序的其他部分分离。添加REST或SOAP API可能会产生类似的效果，但构建HTTP连接以访问数据库可能会降低应用程序的速度。