システムアーキテクチャ設計メソトロジー

システムアーキテクチャ設計のメソトロジー（方法論）をメモ。

アプリケーションの原則とアーキテクチャパターン(Application Principle and Architecture Pattern)

アプリケーションの原理

特別な理由がない限り、則ることが望ましいアプリケーション開発（アーキテクチャ設計）の原則。
これらの原則はアーキテクチャを抽象化し、複雑性の排除や（アーキテクチャの）リスクを管理するのに役立つ。

繰り返しを避ける（DRY:Don’t Repeat Yourself）

各機能の実装は一度だけ
ソフトウェアやハードウェアに機能的な重複があることは望ましくない
「自分自身だけでなく他人の発明を繰り返さない」という点も同様。
例えば、すでに世の中で開発されている機能（例えばOSSとして一般的に広く普及している）を独自に開発する”車輪の再発明”をしないということ。全てを自分自身で一から作る必要はない。

短くシンプルに（KISSの原則）

Keep it simple, stupid.（シンプルにしておけ！この間抜け）。設計の単純性（簡潔性）は成功への鍵で、不必要な複雑性は避けるべきという原則
要件を満たすシンプルなソリューション
必要に迫られるまで不必要な機能は作らない（将来必要になるであろうという想像で余計な機能を作らない）。これはYAGNIの法則と呼ばれる（You Aren’t Going to Need it.の略で「それはきっと必要にならない」という意）。

目的に沿う

必要十分なソリューションを検討する。それ以上でもそれ以下でもない。

車輪の再発明をしない

目的を達成するためにすでに利用可能なものがあるならば利用する
何かを変えるためだけに時間とお金を浪費しない

失敗に備える

アーキテクチャは大なり小なり失敗するもの
アーキテクチャは失敗を許容するように、もしくは（失敗したとしても）適切に失敗するように設計されるべき
復旧の手段やプロセスを定義する

分割（責任分担）

複雑性を管理するために、アーキテクチャの構成要素は役割ごとに分離されるべき
例えばクラス、アーキテクチャ層、サービス、アプリケーション、サブシステム間で役割が明確に分離する
例えばプレゼンテーション、ビジネスロジック、データアクセスの各レイヤーを分離する

カプセル化（ブラックボックス）

自分たちのアーキテクチャの複雑性を公開しない。自分たちのやり方(How to do)ではなく自分たちがしていること(What to do)を外部に公開する
外部には関係のない複雑性から切り離す
疎結合の促進

アーキテクチャパターン

一般的なアーキテクチャパターン。一般的にシステムが一定以上の規模になると、複数の異なるアーキテクチャパターンの組み合わせで構築される。

インフラストラクチャとプラットフォームのアーキテクチャパターン

水平スケーリング（負荷分散やクラスタリングなどのサブパターン付き）
垂直スケーリング
仮想化（仮想マシン、仮想ネットワークなどのサブパターン付き）
３層アーキテクチャ
DMZ
ソフトウェアアプライアンスなど

アプリケーションアーキテクチャパターン

MVCモデル
ステートマシン
ルールエンジンなど

統合アーキテクチャパターン

サービスバス
アダプタ
ETL
ハブアンドスポーク
RESTなど

アーキテクトは、どのパターンをソリューションとして適用するか決定しなければならない。
また、アーキテクチャパターンの重要な要素に、「アプリケーションスタイル」がある。
例えば「Web」、「ポータル」、「バッチ」、「統合」、「レポート作成」などだ。

ちなみに、1994年“Gang of Four”（Eric Gamma、Richard Helm、Ralph Johnson、John Vlissides）は、Object-Oriented Designに焦点を当てた、ソフトウェア設計における一般的な問題に対する繰り返しの解決策（パターン）を記した、Design Patternsに関する著書を発行しました。この本では、多くのアーキテクチャパターンについて記されており、システムアーキテクトにとっては必読の内容となっている。

機能的／技術的ケーパビリティ(Functional and Technical Capabilities )

ケーパビリティとは、エンタープライズ、システム、またはアプリケーションが行うべきことを捉える概念レベルの要素。
通常、ケーパビリティは3つのタイプ（開発・実行・運用）のそれぞれについて設計される。

3つのタイプ

開発アーキテクチャ(Development)

アプリケーション（またはシステム）の開発およびテストに必要な機能。
例）構成管理機能、パフォーマンステストのための機能（負荷ツールやそれ用の環境）など

実行アーキテクチャ(Runtime)

アプリケーション（またはシステム）が使用されるときに実行する必要がある処理。
例）Logging、バリデーションチェック、データ保存など

運用アーキテクチャ(Operations)

システム運用において必要な機能
例）監視・報知、バックアップなど

機能的ケーパビリティ

業界固有の業務要件。一般的にすべてランタイムアーキテクチャに含まれる。
例）割引計算、注文、および決済などは機能的ケーパビリティであり、パッケージ（またはカスタムソフトウェア）を介して実施される。

技術的ケーパビリティ

すべてのソリューションで必ずしも必要というわけではないが、さまざまなソリューションで共通して使用される技術的構成要素。
例えば、暗号化やデータ持続性およびメッセージルーティングは技術的ケーパビリティであり、典型的にはハードウェア、ミドルウェア（例えばRDBMSやWeb/APサーバやメッセージングソフト）やアプリケーションと構成の組み合わせで実現される。

アーキテクチャコンポーネント(Architecture Components)

アーキテクチャを構成する各コンポーネント。ハードウェアやらソフトウェアやらデータなど。

インフラアーキテクチャ

サーバー、ネットワーク、およびストレージを示すインフラアーキテクチャ。

プラットフォームアーキテクチャ

インフラ上で動作し、複数のアプリケーションに使用されるコンポーネント。データベース、アプリケーションランタイム、アプリケーションフレームワークなど。

データアーキテクチャ

どのデータ要素がどのプラットフォームコンポーネントに格納されているか、およびプラットフォームコンポーネント間でデータが連携されるかを示す。データモデルを含む。

アプリケーションアーキテクチャ

プラットフォーム上で実行されているアプリケーションコンポーネント（各業務機能ドメイン）が互いにどのように関連し、アプリケーションまたはシステムを構成しているかを示す。