マイクロサービスアーキテクチャのコンテキストでの正規スキーマとは何ですか？
最近の質問 は、マイクロサービスアーキテクチャのコンテキストでcanonical schemaという用語に言及しました。 Wikipediaの記事 を読んだ後、質問に対して 回答の1つ と同様に、まだ何がわからないのかcanonical schemais about。データモデルで魔法をかけることでマイクロサービスを分離する方法だと思いますが、パターンの具体的なアプリケーションに関しては迷っています。 その他のリソース は、標準化された情報セットについて話しているため、物事はよりわかりにくくなっています。
マイクロサービスAがメッセージキューサービスを介してマイクロサービスBからのメッセージを消費しているとしましょう。これらのJSONメッセージに、倉庫内の製品の在庫状況に関する情報が含まれているとしましょう。 AはBの存在や場所について何も知る必要はありませんが、次のことを知る必要があると思います。
メッセージがJSONを使用してフォーマットされていること。 Bが突然XMLでメッセージのフォーマットを開始した場合、両方のJSONを処理するように特別にプログラムされていない限り、Aがどのように魔法のように適応するかはほとんどわかりませんおよびXMLメッセージ。
Aが使用する部分に限定された実際のデータモデル。Aが製品IDと在庫状況を必要とするだけの場合、Aは、JSONメッセージに製品のフルネームまたは倉庫内の場所も含まれていることを気にする必要がない場合があります。ただし、製品IDがフィールド
/product/idに格納され、GUIDとしてフォーマットされていること、および数量が/quantityに格納されており、数値としてフォーマットされていることを知っている必要があります。繰り返しになりますが、Bが製品のlongベースのIDに切り替えた場合、プログラマーがこの潜在的なフォーマット変更を念頭に置いていない限り、Aはそれを処理できません。
では、このデザインパターンとは何か、そして実際にどのように使用されているのでしょうか。サービスAとBの例で、標準的なスキーマパターンが適用されるとどうなりますか？
たぶん、それはすべてAがBのスキーマを読み取り、それに動的に適応することに関するものでしょうか？つまり、Swaggerとまったく同じであり、実行時にWSDLを読み取り、SOAPサービスを呼び出す方法を決定することと同様です。
上記のどれでもない。記事（およびリンク先の投稿）は、特にMicroServicesはnotが正規スキーマを使用する傾向があると具体的に述べています。
正規スキーマには魔法はありません。その要点は、SOAエコシステム内では、特定の「もの」の共通のモデルとフォーマットを持っているということです。これは契約のようなものです。「ユーザーオブジェクトを表すときはいつでも、次のスキーマ： "。
対照的に、マイクロサービスは、独自のデータニーズを適用し、内部的に、または別のサービスと通信するときに必要なあらゆる変換を行う傾向があります。動的スキーマの変更はまだありません。