コンポーネントベースのアーキテクチャとは何ですか?

コンポーネントアーキテクチャは、再利用可能なコンポーネントに基づいてソフトウェアを構築するためのフレームワークです。 各コンポーネントは、明確に定義された機能をバイナリユニットにカプセル化します。このバイナリユニットは、他のコンポーネントを変更することなく、ライブラリに保存してアプリケーションにドロップできます。

利点は、開発とテストの時間の短縮、信頼性の向上(コンポーネントが事前にテストされているため)、およびコンポーネントを追加または交換することでアプリケーションを変更できる柔軟性です。

ビルディングブロックとしてのコンポーネント

コンポーネントベースのアーキテクチャとは何ですか?コンポーネントをレゴブロックと考えてください。レゴブロックから構造物を構築する場合、さまざまな形、サイズ、色から選択できます。ドア、窓、その他の構造要素として専用に作られたブロックもあります。各ブロックには、他のブロックに接続するために必要なすべての機能があり、ブロックを追加または削除しても、通常、構造への影響は最小限に抑えられます。

もちろん、ソフトウェアは小さなプラスチック片よりもはるかに複雑ですが、概念は似ています。各コンポーネントは、アーキテクチャによって定義された方法でタスクを実行するように構築されています。コンポーネントはライブラリに保存され、開発者によって組み立てられます。コンポーネントは、簡単にするためにアプリケーションプログラムインターフェイスを介して相互に通信します。通信は、すべてのコンポーネントが使用する単一の通信プレーンを提供するため、「ソフトウェアバス」と呼ばれることもあるオブジェクトリクエストブローカによって促進されます。通信は、非同期、ブロードキャスト、メッセージ駆動型システム、または進行中のデータストリームの一部など、さまざまな方法で発生する可能性があります。

この概念は新しいものではなく、1960年代後半には学術論文で議論されてきました。 1990年代初頭に導入されたIBMのシステムオブジェクトモデルは、コンポーネントからソフトウェアを構築する方法を定義する最初の商業的取り組みでした。 ほぼ同時期に導入されたMicrosoftのコンポーネントオブジェクトモデルオブジェクトリンクおよび埋め込みは、商用展開で使用するための最初のフレームワークを提供しました。

コンポーネントの機能

ソフトウェアコンポーネントには、いくつかの共通の特徴があります:

  • 再利用性:これらは、変更や特別な調整を必要とせずに、さまざまなアプリケーションにプラグインできるように設計されています。
  • 拡張性:コンポーネントを他のコンポーネントと組み合わせて、新しい動作を作成できます。
  • 交換可能性:同様の機能を持つコンポーネントは交換できます。
  • カプセル化:コンポーネントは自己完結型であり、内部プロセスの詳細を隠しながら、インターフェースを介して機能を公開します。
  • 独立:コンポーネントは他のコンポーネントへの依存関係が最小限であり、さまざまな環境やコンテキストで動作できます。

コンポーネントの例

コンポーネントは、サービス指向およびマイクロサービスアーキテクチャの構成要素であり、アプリケーションは疎結合の個別のサービスから組み立てられます。 マイクロサービスは、DevOpsおよびクラウドネイティブ開発で使用される主要なアーキテクチャです。 開発者はアプリケーションを最初から構築するのではなく、ほとんどのアプリケーションをアセンブルするため、生産性のメリットが高く評価されています。

コンポーネントの一例は、Microsoft PowerPointのスプレッドシート機能です。 チャートまたはグラフの基礎となるデータを編集すると、MicrosoftExcelのように見えて動作するスプレッドシートがユーザーに表示されます。 Excelのフルバージョンではありませんが、スプレッドシートウィジェットには、基本的なスプレッドシート機能をサポートするのに十分な機能があります。

コンポーネントの他の例には、eコマーストランザクションで税金を計算する関数、またはログイン時にユーザーに質問に答えるように要求する関数が含まれます。

関連する読み物: The Top 5 Benefits of Developing with Containers

コンポーネントとのトレードオフ

コンポーネントアーキテクチャにはいくつかの欠点があります。つまり、すべてのシナリオに適しているわけではありません。 1つには、アプリケーションをモジュール式で機能的に分離された部分に分割する必要があります。これは、アプリケーションが非常に大きい場合に課題となる可能性があります。 また、コンポーネントの再利用性の必要性により、そのカスタマイズオプションが制限される可能性があります。

アプリケーションの要件に完全に一致するコンポーネントを見つけることも難しい場合があります。また、特定のアプリケーションで非常に多くのコンポーネントを監視する必要があるため、コンポーネントライブラリの更新と保守が複雑になる可能性があります。

コンポーネントの代替

コンポーネントベースのアーキテクチャには多くの選択肢があります。 これらには以下が含まれます:

  • マイクロカーネルアーキテクチャは、コア処理コンポーネントと、特定の機能を備えた独立したプラグインモジュールで構成されています。 コンポーネントは相互に通信せず、マイクロカーネルとのみ通信します。
  • クライアント/サーバーアーキテクチャには、データ、サービス、およびコンテンツの要求を交換する2つのコンポーネント(クライアントとサーバー)があります。 それ以外の場合、それらはほとんど独立して動作します。
  • イベント駆動型アーキテクチャは、クレジットカードがスワイプされたり、センサーによってアラートが生成されたりするなどのイベントに応答して動作する、分離された専用のソフトウェアモジュールで構成されています。

コンポーネントは、最新のソフトウェアの基本的な構成要素になっています。 この用語は20年前よりも今日ではあまり使用されていませんが、概念は健全であり、絶えず変化するテクノロジー環境に適応できることが証明されています。