サービス指向とオブジェクト指向-共存できますか？

StackOverflow https://stackoverflow.com/questions/442815

  •  22-07-2019
  •  | 
  •  

質問

Service-Oriented Architecture （SOA）に多くの関心が寄せられています最近会社。私たちがそれをどのように使用するかを見ようとするたびに、私は常に精神的なブロックに立ち向かいます。粗雑：

  • オブジェクト指向では、「データ（ビジネスプロセス）を一緒に操作するデータとメソッドを保持する」＆quot;

  • サービス指向：「サービス内のビジネスプロセスを保持し、データを渡す」

SOAを開発する以前の試みは、オブジェクト指向コードをデータ構造に変換し、それらを操作する別の手順（サービス）に変換することになりました。

私の質問は次のとおりです。 SOAとOOの連携を可能にするパターン、アーキテクチャ、戦略など

編集：「内部向けにはオブジェクト指向、システム境界にはSOA」という回答。素晴らしいと便利ですが、これは私が得ていたものではありません。

別のアカウントと結合する Merge というビジネスオペレーションを持つ Account オブジェクトがあるとします。典型的なオブジェクト指向のアプローチは次のようになります。

Account mainAccount = database.loadAccount(mainId);
Account lesserAccount = database.loadAccount(lesserId);

mainAccount.mergeWith(lesserAccount);

mainAccount.save();
lesserAccount.delete();

これまで見てきたSOAの同等物は次のようになります。

Account mainAccount = accountService.loadAccount(mainId);
Account lesserAccount = accountService.loadAccount(lesserId);

accountService.merge(mainAccount, lesserAccount);
// save and delete handled by the service

OOの場合、ビジネスロジック（およびActiveRecordパターンによるエンティティ認識）は、 Account クラスに組み込まれます。 SOAの場合、ビジネスルールはすべてサービスに埋め込まれているため、 Account オブジェクトは実際には単なる構造です。

リッチで機能的なクラスと再利用可能なサービスを同時に使用できますか？

役に立ちましたか？

解決

SOAは外部インターフェイス（一般的には社外のインターフェイス）にのみ有用であると本当に思います。それでも、パフォーマンスがそれほど重要でない場合にのみ、メッセージの順序付き配信は必要ありません。

その観点から、それらは共存できると思います。 OOの哲学を使用してアプリケーションの動作と通信を維持し、（サードパーティへの）外部インターフェイスが必要な場合にのみ、SOAを介して公開します（これは必須ではありませんが、1つの方法です）。

SOAが過剰に使用されている、または少なくともSOAを使用したアーキテクチャが頻繁に提案されていると感じています。内部的にSOAを使用する大規模なシステムはまったく知りません。マッシュアップや単純な天気予報タイプのリクエストに使用するだけで、真面目にシステムを構築するのではなく、より多くのことのように思えます。

他のヒント

SOAはマクロレベルでは有用ですが、各サービスはおそらくいくつかの内部コンポーネントを必要とするだけの大きさになると思います。内部コンポーネントは、OOアーキテクチャの恩恵を受ける可能性があります。

SOA APIは外部APIであるため、内部APIよりも慎重に定義する必要があります。このレベルで渡されるデータ型は、内部ロジックを使用せずに、できるだけシンプルにする必要があります。データ型に属するロジック（検証など）がある場合、データ型でのロジックの実行を担当するサービスが1つあることが望ましいです。

SOAは、システムまたはアプリケーション間の通信に適したアーキテクチャです。

各アプリケーションは「サービス」を定義します;処理するリクエストと期待されるレスポーズで構成されるインターフェース。

ここでのキーポイントは、明確に定義されたインターフェイスを備えた明確に定義されたサービスです。サービスが実際にどのように実装されるかは、SOAに関しては無関係です。

したがって、すべての最新かつ最高のオブジェクト指向テクニーク、またはあなたのために働く他の方法論を使用して、あなたのサービスを自由に実装できます。 （「サービス」が実際の人間が画面にデータを入力することによって実装されるという極端なケースを見てきましたが、それでもすべてが教科書SOAでした！）

これはオブジェクトの方向の誤解だと思います。 Javaでも、メソッドは通常オブジェクトの一部ではなく、クラスの一部です（そして、この「メンバーシップ」もオブジェクト指向には必要ありませんが、それは別の件名）。クラスは型の単なる説明であるため、これはデータではなくプログラムの一部です。

SOAとOOは互いに矛盾しません。サービスはデータを受け入れ、それらを内部でオブジェクトに整理し、それらを処理し、最終的には希望する形式で返すことができます。

James GoslingがCOBOLでSOAを実装できると言っているのを聞いたことがあります。

AOPの起源に関するAlan Kay自身の説明を読むと、何か有用なことを実行するために相互作用している小さなコンピューターの束が説明されています。

この説明を考慮してください：

  

XはYで構成されている必要があります。各Yは、単一のコンセプトを担当し、そのインターフェースの観点から完全に説明できる必要があります。あるYは、（指定されたインターフェイスごとに）メッセージの交換を介して別のYに何かを依頼することができます。

     

場合によっては、XはZによって実装される場合があり、Zはそのインターフェイスに従って管理します。 Xは別のXのZに直接アクセスできません。

次の置換が可能だと思います：

Term      Programing       Architecture
----    ---------------    ------------
  X         Program           System
  Y         Objects          Services
  Z      Data structure      Database
----    ---------------    ------------
result        OOP              SOA

主にカプセル化、情報の隠蔽、疎結合、ブラックボックスインターフェイスの観点から考えると、かなりの類似点があります。ポリモーフィズムや継承などで動けなくなった場合、私見ではなく、アーキテクチャ/プログラミングではなくプログラミング/実装を考えていることになります。

サービスが状態を記憶することを許可する場合、サービスは、呼び出し時間が遅い可能性のある大きなオブジェクトと見なすことができます。

状態を保持することが許可されていない場合は、前述のとおり-データの演算子です。

システムをあまりにも多くのサービスに分割しているようです。分割方法について相互に合意した基準を書いていますか？

SOAを採用するということは、すべてのオブジェクトを破棄するという意味ではありませんが、システムを再利用可能な大きなチャンクに分割することです。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top