【アーキテクチャ アンチパターン】Architecture By Implication
どんな問題？
アーキテクチャ仕様の不足という一言でまとめられる．
具体的には以下の不足項目がある
- ソフトアーキテクチャと仕様
- 言語，ライブラリ，コーディング規約，メモリ管理など
- ハードアーキテクチャ
- 通信アーキテクチャ
- Persistenceアーキテクチャ
- データベース，file-handling mechanism
- アプリセキュリティアーキテクチャ
- スレッドモデル，trusted system base
- システム管理アーキテクチャ
どんなときに起こる?
- アーキテクチャの計画と仕様が不足しているとき
- 上記の不足項目参照
- 潜在的なリスクがあるとき
- スケール，ドメイン知識，技術，複雑性，プロジェクトが進むにつれて発生するすべてのもの
- 新技術を使わないとき
- 技術的なバックアップや危機回避策がないとき
どう解決する？
アーキテクチャの定義を行う．
その際，システムのいろいろなステークホルダからのビューが重要．
それぞれのステークホルダは優先度の意識を持っており，なにが重要かという問いに答えることができる．
これらのビューを文書化することが大事．
この文書を通じて，アーキテクチャ的に重要な決め事や関心事に取り組める．
ビューポイントを用いたアーキテクチャ定義のステップは下記のようになる．
- アーキテクチャの目標を定める
- なにをアーキテクチャは成し遂げるのか．
- どんなステークホルダの要求が満たされないといけないのか．
- システムの将来像は何か．
- 現時点の進捗はいくらか．
- 疑問を定める
- どんな質問があればステークホルダの疑義を満足できるのか
- ビューを選択する際の優先的な疑義を見つける．
- ビューを選択する
- 各ビューがシステムのblueprintを描く
- 各ビューを分析する
- アーキテクチャを各ビューから定義する．
- blueprintを統合する
- viewをたどってニーズを探す．
- アーキテクチャ記述にないgapを探す必要がある．
- blueprintを描くのを繰り返す．
- すべての疑義を繰り返し検討してgapを解消する．
- review processを利用する．
- アーキテクチャをさらに推進する．
- ステークホルダにアーキテクチャについて話す．
- 実装をはじめる．
上記のステップをgoal-question architecture(GOA)と呼ぶ．
