ソフトウェアアーキテクチャの全て

　ソフトウェア開発は、それに関連するビジネスだけでなく、さまざまな技術分野の専門知識を必要とする複雑な体系的なプロセスです。ソフトウェア開発プロセスで大事なことは、ソフトウェアのアーキテクチャを定義することです。

なぜソフトウェアアーキテクチャが必要なのか

　昔のエンジニアたちは、アーキテクチャの低いソフトウェアを設計していいたようです。計画のオーバーヘッドがないので、プロトタイプ作成が高速であるという利点があるように見えます。しかし、彼らがプロセスに深く入り込むにつれて、ソフトウェアは泥だんごのように柔軟性がなくなり、管理が難しくなります。変更のたびにコストがかかるため、このアプローチの仕方を見直す必要がありました。

　このようなプロジェクトは時間の経過とともに管理が難しくなります。そのためアップデートが制限されてしまうのです。

　ソフトウェア設計の何年にもわたる進化の中で、エンジニアの世界は、アーキテクチャのないソフトウェア設計の問題を回避するために、いくつかのアーキテクチャアプローチを考え出しました。 以下は最も有名なもののいくつかです。

• 階層化アーキテクチャ
• 階層型アーキテクチャ
• サービス指向アーキテクチャ（SOA）
• マイクロサービスアーキテクチャ

階層化アーキテクチャ

　ソフトウェア設計は、互いに重ねられた層に分割されます。 各レイヤーは専用の役割を果たします。

• プレゼンテーション層
• ビジネスロジック層
• データリンク層

プレゼンテーション層は、外界と相互作用するユーザーインターフェイスを保持します。これは、エンドユーザーとの対話のために公開される唯一のレイヤーであるため、UXを提供する役割もあります。

ビジネスロジック層は、ソフトウェアアプリケーションのビジネスロジックを保持します。このレイヤーは、UI / UXをビジネス関連の計算から切り離し、他のレイヤーに影響を与えることなく、絶えず変化するビジネス要件に応じてロジックを変更する柔軟性を提供します。

データリンク層は、データベースや、ドメイン固有ではない（つまり、ビジネスに関連しない）その他のデータ処理などの永続ストレージとの対話の役割を持ちます。

利点

• 他のアプローチと比較して実装が簡単
• レイヤー間の分離による抽象化を提供する
• レイヤー間の分離により、他のレイヤーが1つのレイヤーの変更から免れるようになる
• 結合度が低いため、ソフトウェアの管理が容易になる

不利益

• スケーラビリティがあまりない
• このアプローチで構築されたソフトウェアは、変更の容易さを欠いたモノリス構造を持つ傾向がある
• 特定のレイヤーからデータを渡す必要がない場合でも、データは各レイヤーから次々に流れる必要がある。この問題は陥没穴問題と呼ばれる。

階層型アーキテクチャ

　このアーキテクチャは、クライアントサーバー通信の原則に基づいてソフトウェアスイートをレイヤーに分割します。アーキテクチャには、データプロバイダーと消費者の間を分離する1つまたは2つのn層システムが含まれています。

　レイヤー間の通信に要求応答パターンを利用します。階層化アーキテクチャとは異なり、水平（高性能ノードでネットワークをスケーリング）または垂直（個々のパフォーマンスを向上させることで各ノードをスケーリング）のいずれかのスケーラビリティを提供できます。

　

単層システム

　このアプローチでは、単一のシステムがサーバーとしてだけでなくクライアントとしても機能し、システム間通信（ISC）の必要性を排除してより容易に展開することができます。したがって、優れた通信速度を提供できます。
　このようなシステムは、小規模なシングルユーザーアプリケーションにのみ適しており、マルチユーザーの複雑なアプリケーションには使用しないでください。

　

2層システム

　こちらはmサーバーとクライアントの2台の物理マシンで構成されます。 これにより、データ管理操作とデータ処理および表現操作を分離できます。

• クライアントは、プレゼンテーション、ビジネスロジック、およびデータリンク層を保持する。
• サーバーはデータベースなどのデータストアを保持する。

3層/ n層システム

　このタイプのアーキテクチャは、水平方向と垂直方向の両方で高度にスケーラブルになります。n層アーキテクチャの実装は一般的にコストがかかりますが、高いパフォーマンスを提供します。したがって、大規模で複雑なソフトウェアソリューションで推奨されます。
　高度なサービス指向アーキテクチャスタイルと組み合わせて、高度に洗練されたモデルを生成できます。このアーキテクチャは、ソフトウェアが複雑で、パフォーマンスとスケーリングが必要な場合に使用することをお勧めです。ただし、リソースと時間の点でコストのかかるアプローチになる可能性があるためです。

サービス指向アーキテクチャー

　サービス指向アーキテクチャー（SOA）は、コンポーネントとアプリケーションが明確に定義されたサービスを使用して通信するサービスベースのアーキテクチャモデルです。
　5つの要素で構成されています。

• サービス
• サービスバス
• サービスのサービスリポジトリカタログ
• SOAセキュリティ
• SOAガバナンス

　クライアントは、ネットワークを介して標準のプロトコルとデータ形式を使用して要求を送信します。この要求は、SOAの心臓部でもあるESBによって処理されます。
　ESBは、オーケストレーションとルーティングの役割があります。ESBは、サービスリポジトリを使用してリクエストを専用サービスに転送します。 この専用サービスは、他のサービスまたはデータベースと対話して、応答ペイロード（応答データ）を構成する場合があります。

　サービスは一般的に2つのタイプに分類されます

• アトミックサービス：これ以上分解できない機能を提供
• 複合サービス：複雑な複合機能を提供するための複数のatmoicサービスの集合体

また、サービスには次のタイプがあります。

• エンティティサービス
• ドメインサービス
• ユーティリティサービス
• 統合サービス
• アプリケーションサービス
• セキュリティー・サービス

マイクロサービスアーキテクチャ

　これは、サービスのコンポーネント化の原則に基づいて機能します。このアーキテクチャは、ソフトウェアをサービスとして定義できるさまざまなコンポーネントに分解します。各サービスは単一の責任を負い、すべてのサービスは本質的に分離されています。 1つのサービスを変更しても、他のサービスに影響を与えることはありません。

マイクロサービスの構成

　独立して拡張できる、分離された簡潔できめの細かいマイクロサービスのアーキテクチャで、このアーキテクチャは次の5つのコンポーネントで構成されています。

• サービス
• サービスバス
• 外部構成
• APIゲートウェイ
• コンテナ

マイクロサービスの特徴

　マイクロサービスアーキテクチャは、次の特性で構成されている必要があります。

• サービスによるコンポーネント化
• ビジネス機能を中心に編成
• プロジェクトではない製品
• スマートエンドポイントとダムパイプ
• 分散型ガバナンス
• 分散型データ管理
• インフラストラクチャの自動化
• 失敗のための設計
• 進化的設計

　さまざまなマイクロサービスをさまざまなチームで個別に進化させ、同時に時間とともに進化できるようにすることをお勧めします。データ通信は標準のプロトコルとデータ形式で行われるため、1つのサービスの構造が共同サービスの機能に影響を与えることはありません。

まとめ

　すべてのソフトウェアアーキテクチャアプローチは、先行アーキテクチャの顕著な問題を解決することを目的として設計されています。さまざまなアプローチに関する適切な知識があると、プロジェクトの効率的なソフトウェアアーキテクチャを設計するのに役立ちます。
　難しい説明や単語が多いですが、より良い開発、ソフトウェアを実現するための設計について少しでも理解していただけたなら幸いです。