soa - SOA - 4 つの原則

Question

SOA と、SOA アプリケーションを作成するために必要な 4 つの原則について読んでいます。さまざまな情報源を試しましたが、説明がねじれています。少し抽象度の低いものを探しています。私の解釈は正しいですか？

4 つの原則は次のとおりです。

1. サービスには明確な境界があります
2. サービスは自律的です
3. サービスは、クラスではなく、スキーマとコントラクトを共有します
4. サービスはポリシーに基づいて相互運用されます

私の解釈は次のとおりです。

1. クライアントが使用できるメソッドは、使いやすく、明確に定義されている必要があります。
2. サービスは他者に依存してはなりません。1 つのサービスの変更が別のサービスに影響を与えることはありません。
3. スキームは送信されるデータを表し、コントラクトにはサービス用に定義されたメソッドが含まれます。システムを疎結合にするには、クラスとオブジェクトの代わりにスキームとコントラクトを共有します。
4. サービスを使用するためのポリシーは、特定のタイプのバインディングが必要であり、それを使用できるようにすることである場合があります。このサービスを使用したい人は、このタイプのバインディングで接続する必要があります。

Answer 1

Programmers.stackexchange.com で回答を得ました。GlenH7からの回答を再投稿しています：

はい、あなたは抽象化にかなり近づいています。

1. はい。よくカプセル化されていることは、これを見る別の方法です。
2. はい、しかし...サービスは、特にコードの重複を回避する場合、機能を他のサービスに依存できます。ここでのニュアンスは依存の定義にあると思います。
3. はい。サービスはスキームのコントラクトを実行します。ユーザーは XYZ データを提供し、サービスは契約ごとに ABC アクションを提供します。
4. 私は、サービスがビジネス ポリシーに反して運営されていると考えています。ビジネス ポリシーは、バインディングを指定するレベルに達してはなりません。ビジネス ポリシーの実装の観点から、コードを複製せずに契約を履行するために、一部のサービスが他のサービスに依存する場所を確認できます。より広いレベルでは、ビジネス ポリシーは一連のルールにすぎません。うまくいけばそれぞれとうまく相互運用するルール。しかし、人事と同じように、ビジネス ルールも互いにうまくいかないという厄介な癖があります。サービスは、これらのビジネス ルールのインスタンス化です。下位レベルの観点から見ると、呼び出し元がアドバタイズされたバインディングを使用しない場合、呼び出し元は (明らかに) サービスを利用できません。だからあなたの主張は正しいが、それはちょっとしたトートロジーであり、そうではない」