主な原則

ソフトウェアアーキテクチャは、システムの組織として説明されます。システムは、定義された機能を実行するコンポーネントのセットを表します。

建築様式

ザ・ architectural style、とも呼ばれます architectural patternは、アプリケーションを形作る一連の原則です。これは、構造組織のパターンの観点から、システムファミリーの抽象的なフレームワークを定義します。

建築様式は責任があります-

コンポーネントとコネクタのレキシコンに、それらを組み合わせる方法に関するルールを提供します。
頻繁に発生する問題の解決策を提供することにより、パーティション分割を改善し、設計の再利用を可能にします。
コンポーネントのコレクション（明確に定義されたインターフェイス、再利用可能、および交換可能のモジュール）とコネクタ（モジュール間の通信リンク）を構成する特定の方法を説明します。

コンピュータベースのシステム用に構築されたソフトウェアは、多くのアーキテクチャスタイルの1つを示しています。各スタイルは、以下を含むシステムカテゴリを記述します-

システムが必要とする機能を実行するコンポーネントタイプのセット。
さまざまなコンポーネント間の通信、調整、および連携を可能にする一連のコネクタ（サブルーチン呼び出し、リモートプロシージャコール、データストリーム、およびソケット）。
コンポーネントを統合してシステムを形成する方法を定義するセマンティック制約。
実行時の相互関係を示すコンポーネントのトポロジレイアウト。

一般的な建築設計

次の表に、主要な重点分野ごとに整理できる建築様式を示します。

カテゴリー	建築デザイン	説明
コミュニケーション	メッセージバス	1つ以上の通信チャネルを使用してメッセージを送受信できるソフトウェアシステムの使用を規定します。
コミュニケーション	サービス指向アーキテクチャー（SOA）	コントラクトとメッセージを使用して、機能をサービスとして公開および消費するアプリケーションを定義します。
展開	クライアントサーバー	システムを2つのアプリケーションに分割し、クライアントがサーバーに要求を出します。
展開	3層またはN層	機能を個別のセグメントに分割します。各セグメントは、物理的に分離されたコンピューター上にある層です。
ドメイン	ドメイン駆動設計	ビジネスドメインのモデリングと、ビジネスドメイン内のエンティティに基づくビジネスオブジェクトの定義に重点を置いています。
構造	コンポーネントベース	アプリケーション設計を、明確に定義された通信インターフェイスを公開する再利用可能な機能コンポーネントまたは論理コンポーネントに分解します。
	レイヤード	アプリケーションの懸念事項を積み重ねられたグループ（レイヤー）に分割します。
	オブジェクト指向	アプリケーションまたはシステムの責任をオブジェクトに分割することに基づいており、各オブジェクトには、オブジェクトに関連するデータと動作が含まれています。

アーキテクチャの種類

企業の観点から見たアーキテクチャには4つのタイプがあり、これらのアーキテクチャを総称して次のように呼びます。 enterprise architecture。

Business architecture −企業内のビジネス、ガバナンス、組織、および主要なビジネスプロセスの戦略を定義し、ビジネスプロセスの分析と設計に焦点を当てます。
Application (software) architecture −個々のアプリケーションシステム、それらの相互作用、および組織のビジネスプロセスとの関係の青写真として機能します。
Information architecture −論理および物理データ資産とデータ管理リソースを定義します。
Information technology (IT) architecture −組織の全体的な情報システムを構成するハードウェアとソフトウェアの構成要素を定義します。

アーキテクチャ設計プロセス

アーキテクチャ設計プロセスは、機能要件と非機能要件を満たすために、システムをさまざまなコンポーネントに分解し、それらの相互作用に焦点を当てています。ソフトウェアアーキテクチャ設計への重要な入力は次のとおりです。

分析タスクによって生成された要件。
ハードウェアアーキテクチャ（ソフトウェアアーキテクトは、ハードウェアアーキテクチャを構成するシステムアーキテクトに要件を提供します）。

アーキテクチャ設計プロセスの結果または出力は、 architectural description。基本的なアーキテクチャ設計プロセスは、次の手順で構成されています。

問題を理解する

これは、後続の設計の品質に影響を与えるため、最も重要なステップです。
問題を明確に理解しなければ、効果的な解決策を生み出すことはできません。
多くのソフトウェアプロジェクトおよび製品は、有効なビジネス上の問題を実際に解決しなかったか、認識可能な投資収益率（ROI）を持っていないため、失敗と見なされます。

設計要素とそれらの関係を特定する

このフェーズでは、システムの境界とコンテキストを定義するためのベースラインを構築します。
機能要件に基づいて、システムを主要コンポーネントに分解します。分解は、要素の粒度を指定せずに設計要素間の依存関係を示す設計構造マトリックス（DSM）を使用してモデル化できます。
このステップでは、アーキテクチャの最初の検証は、いくつかのシステムインスタンスを記述することによって実行され、このステップは、機能ベースのアーキテクチャ設計と呼ばれます。

アーキテクチャ設計を評価する

各品質属性には見積もりが与えられるため、定性的測定または定量的データを収集するために、設計が評価されます。
これには、アーキテクチャの品質属性要件への準拠についてアーキテクチャを評価することが含まれます。
推定されたすべての品質属性が必要な基準に従っている場合、建築設計プロセスは終了です。
そうでない場合は、ソフトウェアアーキテクチャ設計の第3フェーズであるアーキテクチャ変換に入ります。観察された品質属性がその要件を満たしていない場合は、新しい設計を作成する必要があります。

アーキテクチャ設計を変革する

このステップは、建築設計の評価後に実行されます。アーキテクチャ設計は、品質属性要件を完全に満たすまで変更する必要があります。
ドメイン機能を維持しながら品質属性を改善するための設計ソリューションの選択に関係しています。
デザインは、デザイン演算子、スタイル、またはパターンを適用することによって変換されます。変換には、既存の設計を採用し、分解、複製、圧縮、抽象化、リソース共有などの設計演算子を適用します。
設計が再度評価され、必要に応じて同じプロセスが複数回繰り返され、再帰的に実行されます。
変換（つまり、品質属性最適化ソリューション）は、一般に1つまたはいくつかの品質属性を改善しますが、他の属性には悪影響を及ぼします。

主要なアーキテクチャの原則

以下は、アーキテクチャを設計する際に考慮すべき重要な原則です。

最後まで構築するのではなく、変更するために構築する

新しい要件や課題に対処するためにアプリケーションを時間の経過とともにどのように変更する必要があるかを検討し、これをサポートする柔軟性を組み込みます。

分析するリスクとモデルを削減する

設計ツール、視覚化、UMLなどのモデリングシステムを使用して、要件と設計上の決定をキャプチャします。影響を分析することもできます。設計を簡単に反復および適合させる機能を抑制する程度にモデルを形式化しないでください。

コミュニケーションおよびコラボレーションツールとしてモデルと視覚化を使用する

優れたアーキテクチャには、設計、決定、および設計に対する継続的な変更の効率的な伝達が不可欠です。アーキテクチャのモデル、ビュー、およびその他の視覚化を使用して、すべての利害関係者と効率的に設計を伝達および共有します。これにより、設計の変更を迅速に伝達できます。

重要なエンジニアリング上の決定と、間違いが最も頻繁に発生する領域を特定して理解します。設計をより柔軟にし、変更によって壊れにくいようにするために、最初に重要な決定を正しく行うことに投資します。

インクリメンタルで反復的なアプローチを使用する

ベースラインアーキテクチャから始めて、アーキテクチャを改善するための反復テストによって候補アーキテクチャを進化させます。複数のパスにわたってデザインに詳細を繰り返し追加して、全体像または適切な全体像を把握し、詳細に焦点を合わせます。

主要な設計原則

以下は、コスト、メンテナンス要件を最小限に抑え、拡張性、アーキテクチャの使いやすさを最大化するために考慮すべき設計原則です。

関心事の分離

システムのコンポーネントを特定の機能に分割して、コンポーネントの機能間で重複がないようにします。これにより、高い凝集度と低い結合度が得られます。このアプローチは、システムのコンポーネント間の相互依存を回避し、システムの保守を容易にします。

単一責任の原則

システムのすべてのモジュールには、ユーザーがシステムを明確に理解するのに役立つ1つの特定の責任が必要です。また、コンポーネントを他のコンポーネントと統合するのにも役立ちます。

最小知識の原則

コンポーネントまたはオブジェクトは、他のコンポーネントの内部の詳細についての知識を持ってはなりません。このアプローチは相互依存を回避し、保守性を向上させます。

大規模設計を事前に最小限に抑える

アプリケーションの要件が不明確な場合は、大規模な設計を事前に最小限に抑えてください。要件を変更する可能性がある場合は、システム全体を大規模に設計することは避けてください。

機能を繰り返さないでください

機能を繰り返さないでください。コンポーネントの機能を繰り返さないように指定します。したがって、コードの一部を1つのコンポーネントにのみ実装する必要があります。アプリケーション内で機能が重複すると、変更の実装が困難になり、明確さが低下し、潜在的な不整合が発生する可能性があります。

機能を再利用しながら、継承よりも構成を優先する

継承は、子と親クラスの間に依存関係を作成するため、子クラスの自由な使用をブロックします。対照的に、構成は大きなレベルの自由を提供し、継承階層を減らします。

コンポーネントを識別し、それらを論理レイヤーにグループ化します

要件を満たすためにシステムで必要とされるIDコンポーネントと関心領域。次に、これらの関連コンポーネントを論理レイヤーにグループ化します。これにより、ユーザーはシステムの構造を高レベルで理解できます。異なるタイプの懸念事項のコンポーネントを同じレイヤーに混在させないでください。

レイヤー間の通信プロトコルを定義する

コンポーネントが相互に通信する方法を理解します。これには、展開シナリオと実稼働環境に関する完全な知識が必要です。

レイヤーのデータ形式を定義する

さまざまなコンポーネントがデータ形式を介して相互作用します。アプリケーションの実装、拡張、保守が容易になるように、データ形式を混在させないでください。レイヤーのデータ形式を同じに保つようにしてください。これにより、さまざまなコンポーネントが相互に通信するときにデータをコーディング/デコードする必要がなくなります。処理のオーバーヘッドを削減します。