これほど内容が気に食わないコンピュータ系の本を読んだのも久しぶりです。 この気に食わなさはなんなのかな？と考えるのが主にこの本を読んでためになった所かなぁ、という気がします。
割といろいろな人に推奨されている本書ですが、 私は超大規模な物を作らざるを得ない人以外は読まなくても良いと思います。
Quality Attributeというのがアーキテクチャの記述では大切な切り口だ、 というのは素晴らしい指摘だと思うのですが、 それ以外の部分はどうも現実的には思えません。
前半でいろいろと理論的な話をするのですが、 後半のケーススタディでは本当にそれの極一部しかうまく使えず、 それまでの話はなんだったんだ、という気がします（特にEJBやWWW、COTSの話は酷い）
Big Design Up Front側の主張も読もうと思って読んだ部分があったこの本なのですが、 肝心の部分の主張もずさんです。
Architectureなどの前段階で時間をかけると、 当然実際に物を目にするのは遅れるので、 どれだけArchitectureの作成の段階で多くの問題を検出出来るか、 が最重要だと思います。
そこで実際にコードが無い状態でどうやって、どこまで評価出来るか、 というのを読んでいったのですが、これが酷い。
評価手法というのは載っていて、その手法自体は使えない訳では無いのですが、
「移植性が大切だ、だからレイヤーパターンを使う事にした」
とか
「パフォーマンスが重要だ。だから並列性を導入した」
とかいう展開で、評価自体はただ一つ一つの要求に対応する上記のような決断があるかを見えるだけ。
今から見るのはフェアでは無いかもしれなけれど、 EJBの話を見ていても明らかにトレードオフをきっちり検討している感じにはなっていません。 想定される問題点や適用すべき規模の大きさすらも議論せずにアーキテクチャの評価と言われても…
全体的にオーバーエンジニアリングかどうかという判定がほとんど無く、 これに間違って影響を受けてしまったアーキテクトが張り切っちゃうプロジェクトは酷い物になりそうだなぁ、 という印象を受けました。
一方で前半はそれなりに形になっています。 最近の話題になると途端に瓦解していきますが、 こういうスタイルがマッチしていた分野はあるのだろうな、というのは感じ取れました。
ただ、私がこれまで行った全ての仕事はそういう分野では無いな、 というのも同時に分かりました。 恐らく世間のかなりの仕事は、この話の適用外です。
影響を受けた部分としてはQuality Attributeの記述以外では、 Architectureの進展に伴い組織構造も変えていく、という例です。 これはなかなか参考になるなぁ、と思ったケーススタディでした。
私の体験でもアーキテクチャの変化、 というよりProduct Lineのライフサイクル上でのステージが変化していくのに大して、 組織構造が古いままで合わなくなっていく、というのは見た事があります。
Product Lineのライフサイクルを意識した上で、どういう風に組織も変化していくべきか？ というのは何度か考えてみています。まだこれ、というような結論は出ていませんが、 この点は有意義だったと思います。
もともと嫌い、という気持ちで読んだからこんなに気に食わないだけかもしれませんが、 食わず嫌いが本当の嫌いに変わっただけでした。
基本的にはきっちり計画派の私ですが、デザインに関してだけはEvansやMartin Fowler側につきます。 コーディングとアーキテクチャの設計は、やはり分離しない方が良い。 それは時代の変化も含まれていて、高速なリファクタリングが可能になった結果として、 コーディング後の構造の変更のコストがかなり安くなった事が起因していると思います。
この話はまたそのうち。
