ソフトウェアアーキテクチャの基礎 第2版 ―エンジニアリングに基づく体系的アプローチ

5章アーキテクチャ特性を明らかにする

アーキテクチャを作成するため、あるいは既存のアーキテクチャの妥当性を判断するために、アーキテクトは2つのことを分析しなければならない。それはアーキテクチャ特性とドメインだ。「4章　アーキテクチャ特性」で説明したように、特定の問題やアプリケーションに適したアーキテクチャ特性（「イリティ（-ility）」）を明らかにするには、ドメインの問題を理解するだけでなく、ステークホルダーと協力し、ドメインの観点から本当に重要なことを見極める必要がある。

プロジェクトに必要なアーキテクチャ特性を明らかにするための箇所は、少なくとも3つある。それはドメインの関心事、プロジェクトの要件、そして暗黙的なドメイン知識だ。暗黙的なアーキテクチャ特性を明らかにする際は、セキュリティやモジュール性といった一般的なものに加えて、ドメイン固有のものにも注意してほしい。たとえば、診断機器から情報を読み取る医療ソフトウェアに取り組むアーキテクトは、データ整合性の重要性やメッセージロスによる潜在的な影響を理解している必要がある。そのドメインで働くアーキテクトはデータ整合性を内面化している。したがって、それは設計するすべてのソリューションで暗黙的に考慮されるものとなる。

5.1　ドメインの関心事からアーキテクチャ特性を捉える

大半のアーキテクチャ特性は、ドメインの主要なステークホルダーに意見を聞き、ビジネスの観点から重要なものを彼らと協力して明らかにすることで得られる。一見すると、これは簡単な作業のように思える。しかし、問題は、アーキテクトとドメインのステークホルダーが異なる言語を話すという所にある。アーキテクトは、スケーラビリティ、相互運用性、耐障害性、学習容易性、可用性などについて語る。一方で、ドメインのステークホルダーは合併や買収、ユーザー満足度、市場投入までの時間、競争優位性について語る。すると、アーキテクトとドメインのステークホルダーとで会話が噛み合わないという「ロスト・イン・トランスレーション」問題が起こる。アーキテクトは、ユーザー満足度をサポートするアーキテクチャをどう作成すればよいかわからない。一方、ドメインのステークホルダーは、なぜ可用性や相互運用性、学習容易性、耐障害性といった特性にこれほど注力するのか理解できない。 ...