我們有一個內部應用程序。隨着時間的推移和新的應用程序的要求，互相之間交換數據，交互變得與數據庫模式綁定。數據庫中的含義變化需要其他地方的變化。由於我們計劃構建更多依賴於相同數據的應用程序，因此這些應用程序很快就會變得混亂無序。爲應用程序交互創建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連接來訪問數據庫可能會減慢應用程序的運行速度。