知っておくべき 14 のソフトウェア・アーキテクチャ・デザイン・パターン

ソフトウェア・アーキテクチャを設計していると、同じ目標や問題に何度も遭遇することがあります。アーキテクチャ・パターンは、一般的な状況に対処する反復可能な設計を提供することで、これらの問題を解決しやすくします。Anand Butani 氏は次のように説明しています。

アーキテクチャ・パターンは、再利用できるように、さまざまなシステムやソフトウェア要素の設計構造を捉えたものです。ソフトウェアコードを作成するプロセスにおいて、開発者はプロジェクト内、社内、あるいはキャリアを通じて、同様の問題に何度も直面します。これに対処する一つの方法は、エンジニアがこれらの問題を解決するための再利用可能な方法を提供するデザイン・パターンを作成することです。これにより、ソフトウェア・エンジニアは特定のプロジェクトにおいて構造的に同じ出力を達成できます。

[ オートメーション・アーキテクト・ハンドブックをダウンロードする ]

ソフトウェア設計にアーキテクチャ・パターンを使用することには、多くの利点があります。効率、生産性、スピードが向上し、開発コストが最適化され、計画が改善されるなど、さまざまなメリットがあります。

活用できるエンタープライズ・アーキテクト・デザイン・パターンには、多くの異なるタイプがあります。プロジェクトに最適なものを判断しやすくするために、以前のアーキテクチャ・デザイン・パターンに関する 14 の記事をまとめ、以下に要約しました。興味のあるものがあれば、リンクをクリックして詳細を確認してください。

14 のソフトウェア・アーキテクチャ・パターン

サーキット・ブレーカー・パターンは、トラフィックを別のサービスに転送することで、障害の影響を最小限に抑えます。システムの耐障害性を高めて事故を未然に防ぐのに役立ちますが、高度なテストやサービスメッシュのようなインフラストラクチャ管理テクノロジーの使用も必要となります。

クライアントサーバー・パターンは、サービスを要求するクライアントと、サービスを提供するサーバーで構成されるピアツーピア・アーキテクチャです。例として、銀行業務、ファイル共有、電子メール、World Wide Web などがあります。このパターンの利点は、データとネットワーク周辺機器が一元管理されることですが、サーバーのコストが高くなります。

CQRS (command query responsibility segregation) パターンは、データの変更よりもデータベース・クエリの方が頻繁に発生する状況に対処します。読み取りと書き込みのアクティビティを分離して、安定性、スケーラビリティ、パフォーマンスを向上させますが、より多くのデータベース・テクノロジーを必要とするため、コストが増加する可能性があります。

コントローラーレスポンダー・パターンは、アーキテクチャを 2 つのコンポーネントに分割します：コントローラーがデータを処理してワークロードを分散し、レスポンダーがコントローラーからのデータを複製して結果を生成します。一つの利点は、コントローラー内のデータに影響を与えずにレスポンダーからデータを読み取れることですが、コントローラーが故障するとデータが失われ、アプリケーションの再起動が必要になる場合があります。

[ 電子ブック「 Kubernetes Patterns ：クラウドネイティブ・アプリケーションを設計するための再利用可能な要素」で、クラウドネイティブ開発の詳細を確認してください ]

イベントソーシング・パターンは、リアルタイム・データを使用するアプリケーションに適しています。データベース、Web サーバー、ログ、またはその他のターゲットにメッセージの連続的なストリームを送信します。非常に柔軟ですが、レイテンシーを最小限に抑えるために、極めて効率的で信頼性の高いネットワーク・インフラストラクチャを必要とします。

レイヤード・パターンは、特定の順序で実行されるサブタスクのグループを含む e コマース、デスクトップ、その他のアプリケーションに適しています。レイヤード・パターンを使用するとアプリケーションを迅速に作成しやすくなりますが、後でレイヤーを分割するのが難しくなるという欠点があります。

マイクロサービス・パターンは、デザイン・パターンを組み合わせて、相互に依存しながら動作する複数のサービスを作成し、大規模なアプリケーションを構築します。個々のアプリケーションが小さいため、必要に応じて更新しやすくなりますが、複雑さが増すため、すべてを正しく機能させるには高度なアーキテクチャの専門知識が必要になります。

MVC (model-view-controller) パターンは、アプリケーションを 3 つのコンポーネントに分割します。 model はアプリケーションのデータと主要な機能を含み、 view はデータを表示してユーザーと対話し、 controller はユーザー入力を処理して model と view の間の仲介役として機能します。このパターンによりアプリケーションはさまざまな表示を生成できますが、抽象化レイヤーによって複雑さが増します。

[ バリデート・パターンの詳細を確認してください ]

パブサブ (pub-sub) パターンは、トピックを購読 (subscribe) している場所に、関連するメッセージを送信 (publish) します。構成は簡単ですが、パブリッシャーとサブスクライバー間のやり取りが非同期であるため、テストがより困難になります。

サガ (saga) パターンは、旅行予約サービスなどの複数のステップを伴うトランザクションに使用されます。サガには、トランザクションを完了するために必要なさまざまなステップが含まれます。このパターンにより、疎結合でメッセージ駆動型の環境でトランザクション (理想的には 5 ステップ以下) を実行できますが、多くのプログラミングが必要であり、管理が複雑になる可能性があります。

シャーディング・パターンは、データベース内のデータをセグメント化して、コマンドやクエリを高速化します。インスタンス全体でストレージが均等に消費されるようになりますが、シャーディングを効果的に管理するには、熟練した経験豊富なデータベース管理者が不可欠です。

静的コンテンツホスティング・パターンは、 Web ページの読み込み時間を最適化するために使用されます。静的コンテンツ (著者の略歴や MP3 ファイルなど、頻繁に変更されない情報) を動的コンテンツ (株価など) とは別に保存します。頻繁に変更されないコンテンツやメディアの配信には非常に効率的ですが、データの整合性やストレージ・コストの増加といった欠点もあります。

ストラングラー・パターンは、システムに対して段階的な変更を行う場合に使用されます。古いシステムを仲介役の後ろに配置して段階的な移行をサポートすることで、大規模な変更を行う場合と比較してリスクを軽減できます。ただし、ルーティングやネットワーク管理に細心の注意を払い、問題が発生した場合に備えてロールバック・プランを用意しておく必要があります。

スロットリング (またはレート制限) パターンは、ターゲットへのデータ流入速度を制御します。分散型サービス拒否 (DDoS) 攻撃中の障害防止や、クラウド・インフラストラクチャ・コストの管理によく使用されます。このパターンを成功させるには、優れた冗長化メカニズムが必要であり、サービスのパフォーマンスを維持するためにサーキット・ブレーカー・パターンと併用されることがよくあります。

まとめ

次に新しいソフトウェア・アーキテクチャに着手するときは、作業の効率を高めるために、これら (または他の多くの) アーキテクチャ・デザイン・パターンのどれを使用できるか検討してみてください。

[ エッジで作業されていますか？ バリデート・パターンの詳細を確認してください ]