## 参考
「FundamentalsOfSoftwareArchitecture.md」という記事を参考にしてます。
https://github.com/zhangjunhd/reading-notes/blob/master/software/FundamentalsOfSoftwareArchitecture.md#13service-based-architecture-style
ちなみのこの記事は「ソフトウェアアーキテクチャの基礎」という書籍の関連資料である。
## オーケストレーション主導のサービス指向アーキテクチャー 概要
このアーキテクチャは「アンチパターン」に属している
「ある組織的な考え方が、理屈は通っていても、開発プロセスの最も重要な部分を妨げてしまうことがある」ということを示すアーキテクチャになってしまっている。
そのデメリットを一言で言うならば、**「再利用性を突き詰めた故の結合」**である
## オーケストレーションアーキテクチャのコンポーネント
- ビジネスサービス
ビジネスサービスはこのアーキテクチャの最上位に位置し、**エントリポイント**を提供します。
これらのサービス定義にはコードは含まれていません。入力、出力、場合によってはスキーマ情報のみが含まれていました。
これらは通常、ビジネスユーザーによって定義されているため、ビジネスサービスと呼ばれています。
- エンタープライズサービス
エンタープライズサービスには、きめ細かい共有実装が含まれています。
通常、開発者のチームは、CreateCustomer、CalculateQuoteなどの**特定のビジネスドメインを中心にアトミックな動作を構築する役割**を担っています。
これらのサービスは、オーケストレーションエンジンを介して結合された、大まかなビジネスサービスを構成するビルディングブロックです。
**この責任の分離は、このアーキテクチャの再利用の目標から生じます。**
- アプリケーションサービス
アーキテクチャ内のすべてのサービスが、エンタープライズサービスと同じレベルの粒度または再利用を必要とするわけではありません。
アプリケーションサービスは、1回限りの単一実装サービスです。
- インフラストラクチャサービス
インフラストラクチャサービスは、**監視、ロギング、認証、承認などの運用上の懸念事項**を提供します。
これらのサービスは、運用と緊密に連携する共有インフラストラクチャチームが所有する、具体的な実装になる傾向があります。
- オーケストレーションエンジン
オーケストレーションエンジンは、**この分散アーキテクチャの中心**を形成し、トランザクション調整やメッセージ変換などの機能を含む、**オーケストレーションを使用したビジネスサービスの実装をつなぎ合わせます。**
オーケストレーションエンジンは、ビジネスサービスとエンタープライズサービスの関係、それらをどのようにマッピングするか、およびトランザクションの境界がどこにあるかを定義します。また、統合ハブとしても機能し、アーキテクトがカスタムコードをパッケージおよびレガシーソフトウェアシステムと統合できるようにします。
- メッセージフロー
すべてのリクエストはオーケストレーションエンジンを通過します。これは、ロジックが存在するこのアーキテクチャ内の場所です。したがって、図16-2に示すように、メッセージフローは、内部呼び出しの場合でもエンジンを通過します。
## 再利用…そして結合
このアーキテクチャの主な目標は、サービスレベルでの再利用です。
つまり、時間の経過とともに段階的に再利用できるビジネス動作を段階的に構築する機能です。
このアーキテクチャのアーキテクトは、可能な限り積極的に再利用の機会を見つけるように指示されました。
## 再利用性のデメリット
例えば一般的な顧客サービスを提供するオブジェクト指向の場合、
以下のようにCustomerオブジェクトを作成するのが普通だ。
しかしこのCustomerオブジェクトはプロジェクト全体でどれくらい使われるだろうか？
たくさん使われると言うことは、その分だけ「結合」が生まれると言うことである。
Customerオブジェクト自体が使われなくても、Personなど継承したオブジェクトを利用するだけで、Customerオブジェクトの結合は生まれるのである。
ここまで育ったプロジェクトのCustomerに対して**一件の情報を付加する**としよう。
**PersonやCompanyクラスなど、どれだけのプログラムが影響を受けるのだろうか？**
## より変更範囲が少ない集約
以下のようにクラスを集めて一つの製品を作るような使い方を**集約**と言う
この場合、継承よりも結合性が弱くなり、改修したい部品にのみプログラムの修理が割り当てられる。
キーボードを改修したければキーボードのクラスを変更すれば良い。
## 備考
img:https://github.com/kawadasatoshi/techblog/blob/main/0/inhouse_se/2007orchastration_driven_arch/2007orchastration_driven_arch.png?raw=true
title:オーケストレーション駆動サービス指向アーキテクチャ
description:このアーキテクチャは「アンチパターン」に属している「ある組織的な考え方が、理屈は通っていても、開発プロセスの最も重要な部分を妨げてしまうことがある」ということを示すアーキテクチャになってしまっている。
category_script:page_name.startswith("2")
