我们有一个内部应用程序。随着时间的推移和新应用程序的请求，在彼此之间交换数据，交互变得绑定到数据库模式。这意味着数据库中的更改需要在其他任何地方进行更改。当我们计划构建更多依赖于相同数据的应用程序时，这将很快变得难以管理。
现在我希望将这种交互抽象化为一个 API。目前我无法选择正确的工具。
有时交互可能很复杂，这意味着数据会发布到一项服务，如果操作已完成，则应通知发送者。
另一个例子是，如果没有来自其他服务的数据，某些数据就没有上下文。可以说，有一项服务是为 [学校] 服务的，一项服务是为 [学生] 服务的。因此，如果 [School] 被删除或更改，则需要立即通知 [Student] 而不是当他来到 [School] 时。
建议？建议？肥皂/休息/？
【问题讨论】：
标签： web-services api rest soap
我认为您不需要 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 并且域逻辑可以询问可以为查询提供服务的数据库适配器。之后，适配器可以向 MySQL 数据库发送例如 SQL 查询并返回响应。通过 ES，您将 EventStorage 添加到系统中，该系统存储引发的域事件。如果您想将数据从一个查询数据库迁移到另一个查询数据库，它会非常有用。在这种情况下，您为新数据库创建一个新的存储适配器，并按历史顺序将 EventStorage 中的所有域事件重播到该适配器，以便它可以用相关数据填充新数据库。就是这样，您不必编写复杂的迁移脚本...
在您的情况下，我认为您至少应该创建域事件，并使用事件溯源。这将使您的数据库与应用程序的其他部分完全分离。添加 REST 或 SOAP API 可以产生类似的效果，但构建 HTTP 连接以访问您的数据库可能会降低您的应用程序的速度。
【讨论】：