ロジック集中化パターン

ロジック集中化は、サービス指向設計パラダイムにおける設計パターンの一つであり、非依存ロジックの再利用性を高めることを目的としています。[1]このパターンは、サービス[2]に冗長な非依存ロジックが含まれないようにし、再利用可能なロジックが機能コンテキストに最も適合したサービス内にカプセル化されることを保証します。[3] [4]

根拠

システム内のサービス数が増加すると、冗長な機能を持つサービスが開発されるリスクがあります。サービス正規化設計パターンを適用することで、こうした冗長性を排除できますが、正規化されたサービスが存在するだけでは、それらのサービスの意図された再利用が保証されるわけではありません。

非依存サービス(再利用可能なロジック[5]を含むサービス)の場合、この問題は実際の再利用を著しく妨げる可能性があります。たとえば、プロジェクトチーム(チームA)は、複雑なデータ構造を必要とする既存のサービスを再利用せず、代わりに当面のニーズを満たす簡素化されたサービスを開発することを選択する場合があります。その結果、同じ再利用可能なロジックが元のサービス内で進化するのではなく、複数のサービス間で重複することになります。別のチーム(チームB)が元のサービス内で必要な機能を検索したものの、適切な実装が見つからず、チームAが新しく作成したサービスを使用することを選択した場合、この問題はさらに複雑になります。その結果、元の非依存サービスの再利用性が低下し、再利用可能なロジックが複数のサービスに分散して配布されるため 、ガバナンスの問題が発生します。

この問題を軽減するために、ロジック集中化設計パターンは、非依存サービスの適切な使用を強制する設計標準を確立します。このアプローチにより、特定の種類の再利用可能なロジックが単一の明確に定義されたサービス内にカプセル化され、サービス利用者は適切なサービスを通じて機能にアクセスしていることを確信できます。[6]

使用法

図A
図 A
既存のレッド サービスを使用する代わりに、プロジェクト チーム 1 は、短期的な要件により適合する新しい冗長レッド サービスを作成します。
図B
図 B
企業全体の設計標準が整備されているため、プロジェクト チーム 2 によって作成された冗長なレッド サービスへのアクセスは制限されており、サービス コンシューマーはプロジェクト チーム 1 によって開発された既存のレッド サービスを確実に使用できます。さらに、プロジェクト チーム 3 は機能が重複する新しいサービスを作成できず、代わりに既存のレッド サービスの進化に貢献します。

ロジック集中化設計パターンは、特定の機能ドメインを表す専用の「公式エンドポイント」(サービス)を確立します。このアプローチでは、同じ機能を提供する代替サービスへのアクセスが制限され、特定の機能タイプに対して単一のサービスのみが利用可能になります。[7]サービスへのアクセスを集中化することで、再利用可能なロジックが単一のサービスインスタンスに限定されるため、ガバナンスの複雑さが軽減されます。

新しい機能が必要になった場合、それが既存サービスの機能範囲内に収まるかどうかを評価します。収まる場合は、新しいサービスを作成するのではなく、既存のサービスに機能を組み込みます。このアプローチでは、ロジックの集中化を徹底するために、企業全体の標準規格が必要です。

サービス開発者がサービス境界を意識できるようにするため、メタデータ集中化設計パターン[8]を適用することができます。これにより、機能コンテキストとサービス機能を文書化する集中型リポジトリの作成が容易になります。さらに、契約集中化設計パターン[9]と併用することで、ロジック集中化は公式エンドポイント[10]設計パターンに貢献します。

ロジック集中化設計パターンは、各サービスに適切なタイプの再利用可能な機能が含まれていることを保証することで、サービスの再利用性サービスの構成可能性の原則をサポートし、効率的なサービスの構成と再利用を促進します。

考慮事項

この設計パターンを効果的に実装するには、企業内のすべてのプロジェクトチームが、アグノスティックスサービスの適切な使用方法を理解し、遵守することが不可欠です。チームは、短期的なプロジェクト要件のみに対応する新しいサービスを作成することは避けなければなりません。これは、冗長性をもたらし、サービスの再利用性の低下につながる可能性があるためです。

このパターンの適用は、既存の非依存型サービスを統合し、確立されたガイドラインに従って進化させるには追加の時間と労力が必要となるため、プロジェクトのデリバリータイムラインに影響を与える可能性があります。場合によっては、プロジェクト内のサービスが、標準化されたアプローチに合わせて設計が変更されるまで、非依存型サービスとすぐに互換性を持たないことがあります。

参考文献

  1. ^ 特定のビジネス プロセスに固有ではなく、複数のプロセス間で再利用できるロジック。
  2. ^ “サービス”. 2012年5月1日時点のオリジナルよりアーカイブ2010年3月9日閲覧。
  3. ^ サービスによって提供される機能の種類。
  4. ^ Kanu Tripathi. 「WS-AtomicTransactionを使用しないサービストランザクション処理」. 2010年4月25日アクセス.
  5. ^ 不可知論ロジックを含むサービス。
  6. ^ デニス・ウィスノスキー「米国国防総省における原則とパターン」Wayback Machineに2010年9月20日アーカイブ。2010年4月25日アクセス。
  7. ^ Matthew Dailey. 「ソフトウェアアーキテクチャ設計:サービス指向アーキテクチャ(パートII)」Wayback Machineに2011年7月24日アーカイブ。2010年4月25日アクセス。
  8. ^ 「メタデータ集中化パターン」
  9. ^ 「契約集中化パターン」
  10. ^ 「公式エンドポイントパターン」
  • SOAの概念
  • SOA用語集
  • SOA設計パターン
「https://en.wikipedia.org/w/index.php?title=Logic_centralization_pattern&oldid=1273479878」から取得