我们有一个内部应用程序。随着时间的推移和新的应用程序的要求，互相之间交换数据，交互变得与数据库模式绑定。数据库中的含义变化需要其他地方的变化。由于我们计划构建更多依赖于相同数据的应用程序，因此这些应用程序很快就会变得混乱无序。为应用程序交互创建API
现在我正在寻找抽象API背后的交互。目前我无法选择合适的工具。
交互有时可能很复杂，这意味着数据被发布到一个服务，如果操作已完成，它应通知发件人。
另一个例子是某些数据没有上下文而没有来自其他服务的数据。假设[学校]有一项服务，[学生]有一项服务。因此，如果[学校]被删除或更改，[学生]需要被非常直接地告知，而不是当他来到[学校]时。
建议？建议？ SOAP/REST /？
我不认为你需要一个API。在我看来，您需要一种将您的数据库与领域逻辑和应用程序的其他部分分离的体系结构。这样的架构例如是clean architecture,onion architecture和hexagonal architecture（ports&adapters通过新名称）。他们共享相同的概念，你有一个域逻辑，它不依赖于任何框架，外部库，交付方法，数据存储解决方案等等。这个域逻辑通过具有定义良好的接口的适配器与外界通信。如果您首先设计了域逻辑的内部以及适配器的接口，并且仅在外部组件之后设计，则称为domain driven design（DDD）。
因此，举例来说，如果你想从MySQL迁移到MongoDB的你已经有了一个DataStorageInterface，你需要的是写一个MongoDBAdapter实现此接口，和OFC迁移数据的唯一的事......
要设计适配器，您可以使用两个额外的概念;命令和查询隔离（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连接来访问数据库可能会减慢应用程序的运行速度。