前提
ソフトウェアアーキテクチャを考える上で越えなくては行けない壁が存在します。
１、要求
２、実装
ソフトウェアアーキテクチャの定義
ソフトウェアアーキテクチャとは？
ソフトウェア開発のライフサイクル全体に影響を与える重要なものです。
ただし、アーキテクチャの定義は曖昧であり、受取り手によって解釈が異なります。
これが原因で対応が困難となり状況が発生することが頻繁にあります。
ここで、一番簡単な定義を見てみましょう。
「ソフトウェアアーキテクチャとは、ソフトウェアシステムのサブシステムまたはコンポーネント、及びそれらの関係を記述したもの」
この他にも、Webで検索してみると、非常に多くの定義が出てくるので、検索して見比べて見てください。
この他にも、Webで検索してみると、非常に多くの定義が出てくるので、検索して見比べて見てください。
ここで更に理解するのを難解にするソフトウェアデザインという概念も一緒に見ていきます。
なぜかと言うと、ソフトウェアアーキテクチャとソフトウェアデザインは似たような意味で用いられるケースが多く、違いを認識しておくことが重要になるからです。
違いを下記にまとめます。
アーキテクチャーは言葉の通り、骨組みです。つまり、必ずしも機能だけに焦点を当てるのではなく、組織や技術・ビジネスサイドも対象にすることがあります。
一方デザインは、システムを構築するのに必要なコンポーネントやサブシステムに焦点を当てます。具体的には、コードやモジュールをどの程度の単位で分けれるかであったり、オブジェクト同士の相互作用をどのように管理するのかなどです。
一方デザインは、システムを構築するのに必要なコンポーネントやサブシステムに焦点を当てます。具体的には、コードやモジュールをどの程度の単位で分けれるかであったり、オブジェクト同士の相互作用をどのように管理するのかなどです。
ソフトウェアアーキテクチャの特性
特性について説明する前に、下記の用語の定義を押さえておいてください。
システム：ある機能を実現するために構成されたコンポーネントの集合
ストラクチャ：原理・原則に従ってグループ化あるいは組織化された要素（ソフトウェア・ハードウェア）の集合
環境：ソフトウェアシステムが構築されるコンテキスト（同じ処理や記述でも状況に応じて動作などが異なる場合に、その選択基準となる判断材料や条件など）または状況
ステークホルダー：この場合は、開発チーム、プロジェクトマネージャー、経営チームなど
ソフトウェアアーキテクチャの特性は下記のようなものがあります
ストラクチャの定義
下記のようにコンポーネントやクラスのダイアグラム図で表現して、複数のサブシステム間の関係性を示す
重要な要素の明確化
システムの中心となる要素を形成しているもの（ブラウザやリモートサーバーなど、複数あっても問題ない。ただし、多すぎるのは問題）
デザインの方針の決定
システム要件を分析した上で、下記のような方針の決定
システムのデプロイメントの選択肢（OSなど）、使用するプロトコルの制限（httpsしか受け付けないなど）、用いる言語
ステークホルダーの要件管理
全ての要求（開発側・マーケティング側など）を満たすことは不可能なので、要件から発生しうる制約を洗い出した上で、その制約を元にトレードオフを考慮した上で、最適な解を選択
システムの文書化
アーキテクチャはシステムの初期要求や制約、ステークホルダーのトレードオフを夫君いるので、変更しうる要求に基づいたアーキテクチャの変更などにシステムの文書化は役立ちます。
パターンへの準拠
ほとんどのアーキテクチャは、これまでに成功したスタイルに乗っ取って構成されています。現在期待されているのは、成功しているパターンをいかに組み合わせて問題を解決するかです。
ここまで色々と説明してきましたが、なぜ、ソフトウェアアーキテクチャが重要なのか？
それは、下記の要素がアーキテクチャに依存しているからです。
スケーラビリティや可用性、セキュリティといった性質は初期の方針に依存する
アーキテクチャを定義しておけば、プロトタイプの構築が容易になり、トップダウンで構築する必要がなくなる。
既存のコンポーネントを利用することができ、一から実装する必要がなくなる。
新しい機能の実装や、パフォーマンスの改善時に、システム変更を最小限に留めることができる
