 |
ドメインインベントリは、サービス指向設計パラダイムに適用される設計パターンであり、これを適用することで、企業全体にわたる単一のサービスプールを作成するのではなく、企業のさまざまなセグメントに対応するサービスプールを作成することが可能になります。この設計パターンは通常、企業内のさまざまなセグメントに同じ設計標準を適用することで、企業全体にわたる単一のサービスインベントリ[1]を作成できない場合に適用されます。トーマス・エルルによるドメインインベントリ設計パターンは、「企業全体の標準化が不可能な場合、再構成を最大化するためにサービスをどのように提供できるか」という問いかけをしており、このポッドキャストの一部として議論されています。
根拠
エンタープライズインベントリ設計パターンのガイドラインによれば、企業全体をカバーする単一のインベントリを作成することは、サービスの標準化、相互運用性、そして容易な構成を可能にするため有益です。しかしながら、企業全体をカバーする単一のインベントリを作成できない状況も考えられます。これには、以下のような様々な理由が考えられます。
- 管理上の問題 (例: サービスを誰が所有し、誰がそのメンテナンスの責任を負うのか)
- 組織はさまざまな地理的場所に分散しています。
- 組織のさまざまなセグメントはさまざまな IT 部門によってサポートされており、使用されるテクノロジは同じではありません。
- 組織の一部のセグメントは、サービス指向への移行の準備ができていない可能性があります。
- SOA の有効性を確認するためだけにパイロット プロジェクトを実施する必要があります。
- 標準化されたサービス契約のガイドラインによれば、企業全体で標準化されたデータ モデルを作成することは非常に難しい場合があります。
- 文化的な問題。たとえば、IT マネージャーがさまざまなプロジェクトの開発方法に対する制御権を放棄したくないなど。
上記の要因を考慮すると、企業内の明確に定義されたドメイン境界にグループの範囲を関連付けた、より小規模なサービスグループを構築する方が現実的です。[2]これはまさに、ドメインインベントリ[3]設計パターンで提唱されているものです。サービスインベントリの範囲を限定することで、関連するサービスグループの開発と管理が容易になります。[4]
使用法
2つのドメインインベントリで構成されるエンタープライズ。各インベントリ内のサービスは、ドメインの確立された境界に従って独立して標準化されています。
この設計パターンを適用するには、企業内に明確に定義された境界を確立する必要があります。これは通常、企業の特定のビジネス領域に対応します。[5]たとえば、営業部門、顧客サービス部門などです。作成されるドメインはビジネス ドメインに関連していることが重要です。これは、時間の経過とともに進化するビジネス モデルとサービス インベントリを同期させるのに役立つためです。明確に定義された境界を確立したら、次のステップは、サービス指向の設計原則が適用される範囲と、データ モデルの作成方法、サービス機能の命名方法など、その他の関連する規則、ルール、制限を規制する一連の設計標準を作成することです。これらの設計標準が整備されることで、それぞれの組織セグメントの制限内で動作するように特別に調整された標準化されたサービス セットを開発できます。サービスは標準化されているため、ブリッジング メカニズムを必要とせずに簡単に構成できます。
考慮事項
ドメインの確立された境界が実際のビジネスドメインと一致しない場合、管理上の重複により、このようなサービスインベントリを維持することが困難になる可能性があります。各ドメインインベントリは、他のドメインインベントリとは異なる可能性のある特定の標準セットに対応しています。その結果、異なるドメインインベントリに属するサービスからソリューションを構成する場合、異なるサービスインベントリ間でメッセージを送信するために、何らかの変換メカニズムが必要になる場合があります。例えば、ドメインインベントリA内のサービスは、ドメインインベントリBに属するサービスが使用するスキーマと比較して、粒度の粗いXMLスキーマを使用している可能性があります。データモデル変換[6] 、データフォーマット変換[7]、プロトコルブリッジング[8]などの設計パターンを適用することで、異なる変換要件に対応できます。[9]
もう 1 つの重要な要素は、異なるプロジェクト チームによって異なるドメイン インベントリが構築されるため、各チームが自動化されている他のビジネス プロセスの要件を認識しておらず、機能が重複するサービスが開発される可能性が高くなることです。
参考文献
- ^ “Service Inventory”. 2010年3月13日時点のオリジナルよりアーカイブ。2010年3月7日閲覧。
- ^ Mauro et al. 標準化されたデバイスサービス - 医療機器のサービス指向統合のための設計パターン [オンライン]. アクセス日: 2010年4月7日
- ^ ドメインインベントリ設計パターン
- ^ Mauro. et al. Service Oriented Device Integration - An Analysis of SOA Design Patterns. Archived 2011-02-03 at the Wayback Machine [Online], pp.1-10, 2010 43rd Hawaii International Conference on System Sciences, 2010. アクセス日: 2010年4月7日.
- ^ Thomas Erl、Herbjörn Wilhelmsen ドメイン インベントリ パターン[オンライン]。アクセス日: 2010 年 4 月 7 日。
- ^ 「データモデル変換設計パターン」。2010年2月13日時点のオリジナルよりアーカイブ。2010年3月7日閲覧。
- ^ データ形式変換設計パターン
- ^ プロトコルブリッジング設計パターン
- ^ Thomas Rischbeck.ESB パターン: ESB とは? Archived 2009-11-15 at the Wayback Machine [Online].アクセス日: 2010 年 4 月 22 日。
さらに読む
- Thomas Erl 他著（2009年）『SOAデザインパターン』Prentice Hall ISBN 0-13-613516-1
- Howard Cohen、Josh Taylor。国防総省における SOA[オンライン]。アクセス日: 2010 年 4 月 7 日。
- Thomas Erl著「SOAデザインパターンの紹介」Wayback Machineに2010年9月12日にアーカイブ[オンライン]。アクセス日：2010年4月7日。
外部リンク
- SOAの概念
- SOA用語集
- SOA設計パターン
