主な原則

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

建築スタイル

アーキテクチャスタイル*は、*アーキテクチャパターン*とも呼ばれ、アプリケーションを形成する一連の原則です。構造的組織のパターンの観点から、システムファミリの抽象的なフレームワークを定義します。

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

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

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

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

共通の建築設計

次の表は、主要なフォーカス領域ごとに整理できるアーキテクチャのスタイルを示しています-

カテゴリー

建築デザイン

説明

コミュニケーション

メッセージバス

1つ以上の通信チャネルを使用してメッセージを送受信できるソフトウェアシステムの使用を規定します。

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

コントラクトとメッセージを使用して、機能をサービスとして公開および使用するアプリケーションを定義します。

展開

クライアントサーバー

システムを2つのアプリケーションに分離し、クライアントがサーバーにリクエストを送信します。

3層またはN層

機能を個別のセグメントに分割します。各セグメントは、物理的に別個のコンピューターにある層です。

ドメイン

ドメイン駆動設計

ビジネスドメインのモデリングと、ビジネスドメイン内のエンティティに基づいたビジネスオブジェクトの定義に焦点を当てています。

構造

コンポーネントベース

アプリケーション設計を、明確に定義された通信インターフェースを公開する再利用可能な機能または論理コンポーネントに分解します。

レイヤード

アプリケーションの懸念事項を積み重ねられたグループ（レイヤー）に分割します。

オブジェクト指向

アプリケーションまたはシステムの責任のオブジェクトへの分割に基づいており、各オブジェクトにはデータとオブジェクトに関連する動作が含まれています。

アーキテクチャの種類

企業の観点からは4種類のアーキテクチャがあり、これらのアーキテクチャはまとめて*エンタープライズアーキテクチャ*と呼ばれます。

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

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

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

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

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

問題を理解する

これは、後続の設計の品質に影響するため、最も重要な手順です。
問題を明確に理解しないと、問題を作成することはできません効果的なソリューション。
多くのソフトウェアプロジェクトおよび製品は、有効なビジネス上の問題を実際に解決したわけではなく、認識可能な投資収益率（ROI）もなかったため、失敗と見なされます。

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

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

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

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

アーキテクチャ設計の変革

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

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

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

最後まで構築するのではなく、変更して構築する

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

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

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

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

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

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

増分および反復アプローチを使用する

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

主要な設計原則

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

関心事の分離

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

単一責任原則

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

最小知識の原理

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

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

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

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

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

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

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

コンポーネントを特定し、論理層にグループ化します

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

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

コンポーネントが相互に通信する方法を理解するには、展開シナリオと運用環境の完全な知識が必要です。

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

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

システムサービスコンポーネントは抽象的である必要があります

セキュリティ、通信、またはロギング、プロファイリング、構成などのシステムサービスに関連するコードは、個別のコンポーネントで抽象化する必要があります。このコードをビジネスロジックと混在させないでください。設計の拡張と保守が容易です。

設計の例外と例外処理メカニズム

事前に例外を定義すると、コンポーネントがエラーや不要な状況をエレガントに管理するのに役立ちます。例外管理はシステム全体で同じです。

命名規則

命名規則は事前に定義する必要があります。これらは、ユーザーがシステムを簡単に理解できるようにする一貫したモデルを提供します。チームメンバーは、他の人が書いたコードを検証する方が簡単であるため、保守性が向上します。

Software-architecture-design-key-principles

目次