アーキテクチャ特性

アーキテクチャが備えている特性のことであり、システムが成功するために必要な運用と設計の基準となるもの

システムの成功基準ともなる

それを定量的or定性的評価ができればそれが維持されていることがシステムの成功条件となる

例えばAvailability(これは分かりやすい)、Reliability、Testability(テスト容易性)、Deployability(デプロイ容易性)、Elasticity(弾力性)など

モジュール性のようなコードレベルの特性からスケーラビリティや弾力性のような運用レベルの特性まで幅広く存在する

アーキテクチャ特性にはシステムの要件に現れるような明示的なものもあれば、記載されない暗黙的なものもある。アーキテクトは暗黙的なアーキテクチャ特性を事前に分析して設計に臨むのが重要となる。

例えば超高速取引(HFT)の企業において、システムの要件で低レイテンシの記載がなかったとしても、アーキテクトはその必要性を理解し、設計の考慮事項に組み込む必要がある

以下の基準のどれかに当てはまるものはアーキテクチャ特性として考慮すべきである

1. 設計の考慮事項として含めなければならないもの（ドメインの要件を除く）

ドメインの要件として必須なものはアーキテクチャ以前の前提条件（要件）なので含まない

パフォーマンスに関連するものや「技術的負債を防ぐ」などは要件に明記されないが、設計上で考慮したり、目標とする事柄であるなら達成すべきアーキテクチャ特性として念頭におくべきである。

2. 設計の構造的側面に影響を与えるもの

例えばセキュリティは予防策が局所的なコーディングのテクニックで済む場合もあれば、特別なアーキテクチャの構造を作りこまなければならない場合もある。後者のように構造に現れる場合は、セキュリティはただのガイドラインに留まらず、考慮すべきアーキテクチャ特性の1つにまで引き上げて考えるべきである。

なるべく少ないアーキテクチャ特性をサポートすべき

大量のアーキテクチャ特性はシステムを複雑化させる

アーキテクチャ特性を吟味し、最小限にとどめることはアーキテクトの重要な仕事でもある

アーキテクチャ特性同士はしばしば相互作用する。トレードオフが生じるのはこのため。

最善のアーキテクチャは狙えないので、少なくとも最悪でないアーキテクチャを狙おう

アーキテクチャ特性の完全なリストは存在しない

ドメインごとに独自の特性を考えてもいい

詳細は書籍pp.60参照

ドメインからアーキテクチャ特性を分析する

ドメインのステークホルダーにヒアリングしながらシステムに必要なアーキテクチャ特性を抽出していく

問題はドメインのステークホルダーはビジネスの言葉を話し、アーキテクチャの言語がわからないので、アーキテクチャ特性をビジネス上の利点に翻訳していく必要があるということ

https://gyazo.com/fe451e57a16095cef43545dd82921f63

市場投入までの時間はアジリティだけではなくテスト容易性とデプロイ容易性も加える必要がある

アーキテクトやステークホルダーはシステムが持つべきアーキテクチャ特性の最終的なリストに優先順位を付けたいと考えるが、これは論争になって時間の無駄に終わることが多い

代わりに主なステークホルダーに最終的なリストから重要な上位三つの特性を順序を付けずに選出してもらうのがよい

合意を得やすいし、ステークホルダーらの間での議論の促進や、トレードオフ分析にも役立つ

最も重要でない・先に犠牲にしてもよい特性を明らかにするという逆からの戦略も、最小限のアーキテクチャ特性のリストを考えるのに役立つ

アーキテクチャ特性の正確なセットを選定することに固執しすぎてもいけない

アーキテクチャレベルで特性をサポートしていなくても、アプリケーションの設計やプログラミング、運用などの様々なテクニックで特性が確保できる

アーキテクチャレベルでのサポートとは、その特性がよりシンプルかつ洗練された形で実現できるという意味であり、他のレベルでの実現よりもコストが安く済むという意味である