アーキテクチャ特性
ドメイン機能には直接関連しない、ソフトウェアが満たさなければならない全てのこと。非機能要件(ネガティブなニュアンスなのであまり好まない)。
アーキテクチャ特性は以下3つの基準を満たす。
- ドメインに依存しない、設計に関する考慮事項を明らかにするもの(明示的)
- 設計の構造的な側面に影響を与えるもの(暗黙的)
- アプリケーションの成功に不可欠か重要なもの
アーキテクチャの運用特性
- 可用性
- 継続性
- パフォーマンス
- 回復性
- 信頼性、安全性
- 堅牢性
- スケーラビリティ
アーキテクチャの構造特性
- 構成容易性
- 拡張性
- インストール性
- 活用性・再利用性
- ローカライゼーション
- メンテナンス容易性
- 可搬性
- アップグレード容易性
アーキテクチャの横断的特性
- アクセシビリティ
- 長期保存性
- 認証
- 認可
- 合法性
- プライバシー
- セキュリティ
- サポート容易性
- ユーザビリティ・達成容易性
アーキテクチャ特性のリストが完全になることはない。
イタリア性
ある会社のイタリア支社で障害が発生し、それがトラウマとなったため、イタリア性 (可用性、回復性、レジリエンス)のアーキテクチャ特性を持つこととなる。
少なくとも最悪ではないアーキテクチャ
トレードオフであるため、決して最善のアーキテクチャを狙ってはいけない。 少なくとも最悪ではないアーキテクチャを狙う。 アーキテクチャ特性が多すぎると、扱いにくい設計となり、うまく機能することはほとんどない。
アーキテクチャ特性とドメインの関心事
全てのアーキテクチャ特性をサポートする汎用アーキテクチャを設計するのはアンチパターンである。
ヴァーサ号
史上最高の船を求めいていたスウェーデン王ダスタフ２世によって建造された軍艦。甲板が２つあり、輸送船と砲艦の２つを兼ね備えていた。大砲の大きさも２倍あったが、極端な重量艦のため沈没した。(現在はストックホルムの博物館に展示されている)
アーキテクチャ特性の定め方
主なステークホルダーに最終的なリストから最も重要な上位３つの特性を順序をつけずに選んでもらう。
優先順位をつけるのはだめ。← 優先順位に対してステークホルダー全員が同意することは滅多にない。
ロスト・イン・トランスレーション問題
アーキテクトはスケーラビリティ、相互運用世、障害性、可用性などについて語るのに対して、 ドメインのステークホルダーは合併や買収、ユーザの満足度などについて語り、会話が噛み合わないことを ロスト・イン・トランスレーション 問題という。
ドメインの関心事とアーキテクチャ特性の翻訳表
| ドメインの関心事 | アーキテクチャ特性 |
|---|---|
| 合併・買収 | 相互運用性、スケーラビリティ、適応性、拡張性 |
| 市場投入までの時間 | アジリティ、テスト容易性、デプロイ容易性 |
| ユーザ満足度 | パフォーマンス、可用性、耐障害性、テスト容易性、デプロイ容易性、アイジリティ、セキュリティ |
| 競争優位性 | アジリティ、テスト容易性、デプロイ容易性、スケーラビリティ、可用性、耐障害性 |
| 時間と予算 | シンプルさ、フィリビリティ |
アーキテクチャ特性の抽出
要件文書からアーキテクチャ特性を判断する。
Architectural Katas
Architectural Katasとは、Ted Newardによって考案されたドメインを対象とした記述からアーキテクチャ特性を導く練習サイト。
Nealによってhttps://nealford.com/katas/ で追加コンテキストセクションを加え、さらなる練習サイトへと更新された。
参考文献
- ソフトウェアアーキテクチャの基礎
