このサイトでマイクロサービスについて読んでいたときに、以下のステートメントに出くわしました。正規スキーマとはどういう意味ですか?ドメインモデルと同じではありませんか?
マイクロサービスアーキテクチャパターンは、正規スキーマの概念など、SOAの他の部分も拒否します。
このサイトでマイクロサービスについて読んでいたときに、以下のステートメントに出くわしました。正規スキーマとはどういう意味ですか?ドメインモデルと同じではありませんか?
マイクロサービスアーキテクチャパターンは、正規スキーマの概念など、SOAの他の部分も拒否します。
回答:
@ArseniMourzenkoコメントを信頼してくれたことを前もって謝罪しましたが、ウィキペディアを読み始めると、Canonical Schemaの意味をすぐに理解しました。
ここで本当の疑いに焦点を当てたOPのコメント
マイクロサービスアーキテクチャでも、要求と応答はいくつかのデータモデルに準拠する必要があると思います。
一部のデータモデルはありますが、この記事は2つ以上のサービス間での「共有」または「共通」のデータモデルに言及しているようです。
Canonicalのスキーマは、ランタイム・データ変換でからサービスを保存することを意図したパターンです。また、コードを複製する手間も省けます。ただし、サービスを外部データモデルに結合することになります。(上にリンクされているウィキペディアのページの図を参照してください)
これは、サービス間で共通の一種の「言語」です。
記事は、MSが住んでいる「エコシステム」からのMSの完全な独立性を強調しているように見えます。
たとえば、ESBについての言及を見てみましょう。
また、ESBの使用を非常に回避し、代わりにマイクロサービス自体にESBのような機能を実装します。
ESBは通常、バスに接続されているすべての人に共通するエンタープライズデータモデル(メッセージ)を要求します。
したがって、記事に戻ると、著者は、MSが外部システム(およびその制約)への接続を拒否するという事実を指摘しているようです。
マイクロサービスは、緊密な結束と疎結合に関するものです。マイクロサービス内では緊密な結束がありますが、マイクロサービス間では疎結合であるため、共有スキーマやデータコントラクトは避けたいと考えています。共通のスキーマを共有することを要求する方法で相互に同期呼び出しを行うマイクロサービスがあることがわかった場合は、サービス境界を誤って定義したことを示している可能性があります。
マイクロサービスは、ドメイン駆動設計の用語では、境界付きコンテキストと密接に連携する必要があります。
If you find that you have microservices making synchronous calls
。必ずしも非同期呼び出しではありません。ESB非同期メッセージでも発生する可能性があります。共有スキーマやデータコントラクトと組み合わせることが重要だと思います。MSアーキテクチャでは、サービス間の通信p2pは回避する必要があると思います。通信は、内部(内部サービスレイヤー)または外部(ESB、キューなど)レイヤーではなく、アプリケーションを介して行われる必要があります