エンタープライズ分散システム内の単一の信頼できる情報源
エンタープライズ分散システム内には、Eコマースサービス、CRM、サポートデスク、ファイナンス、請求など、多くのサービスがあります。これらのサービスの多くは、Customerデータなどの共通データを共有しています。
これらのサービスは、Enterprise Service Bus（ESB）を使用して相互に通信し、すべてのシステムのデータが最終的に相互に整合するようにします。
私の質問は次のとおりです。1つのシステムのみがデータの一部を更新できることを保証する方が良いですか？真実の単一のソースを持つこと。例えば。課金システムのみがお客様の課金情報を更新できます。 CRMのみがお客様の連絡先の詳細を更新できますか？
私にとって、更新したいデータの正しいシステムを見つけるのは面倒で混乱しているように思えます。更新用に複数のソースを用意しておくと、ESBがこれらの更新をサブスクライブしたサービスに伝達する方がよくわかります。
たとえば、お客様のクレジットカード情報など、かなりニッチなデータであるため、一部のデータには単一の真実（SSOT）のソースがあることがわかります。
異なるサービスから更新される可能性のある一般的なデータを処理するために一般的に採用されている手法は何ですか？エンタープライズ分散システムではSSOTが必要ですか？
私が知っている最もアーキテクチャ的に健全なアプローチは、その単一の真の情報源をマイクロサービスの背後に置くことです。システムの複数の部分がそのデータを更新することは完全に問題ありませんが、マイクロサービスのようなものを介して、常に正しく予測どおりに実行されることを保証できます。
したがって、たとえば、顧客データはおそらくデータベースに既に存在しますが、顧客データのすべての読み取りと書き込みは、顧客データを操作するための制限されたインターフェイスを提供することを唯一の目的とする単一のサービスを経由する必要があります。これにより、検証ロジックやクエリの最適化などの共通の場所が提供され、データへの変更は常に事前に考えた非常に特定の方法で行われ、問題がないことが確実になります。たとえば、顧客が削除すると、その顧客のすべてのクレジットカードデータも削除されるようにするdeleteCustomerリクエストを提供できます。これにより、将来、基になるデータベーステーブルを簡単に変更できるようになります。
正しいマイクロサービスを見つけることは、正しいデータベーステーブルを見つけることと同じくらい簡単で、マイクロサービスのAPI shouldは、データベーススキーマよりもはるかに簡単に正しく使用できます。また、非常に薄いラッパーである必要があります。私が使用して職場で作成するもののほとんどは、各要求を単一のSQLステートメントにマッピングするだけです。クレジットカードの詳細を使用して誰かに請求したり、アイテムの配送を設定したりするなど、より興味深いロジックは別の場所にあります。