「間違いだらけのソフトウェア・アーキテクチャ」読んだ

「間違いだらけのソフトウェア・アーキテクチャ ― 非機能要件の開発と評価」という本を読んだ。

全体的な感想としては、システムのアーキテクチャを考える人、つまりアーキテクトとして振る舞う人が最初にざっくり全体観をつかむために読むとよさそうだな、と思った。例えばエリック・エヴァンスの DDD 本とかあるいはマーティン・ファウラーの PofEAA 本とか読んだけどなんかしっくり来ない、みたいな人が読むとそれらの本のコンテキストが理解できるようになる、みたいな感じ。

個人的に印象を受けたポイント。ぼくは設計をすることにいっぱいいっぱいになってたんだけど、アーキテクチャの役割が理解できて、なんで設計するのかをわかるようになった気がするので、これからはより価値が高い設計ができそう。以前、職場の上司に「まずはユースケースは必ず抑えておこう。そうすればなにかしら使えるものができるから。」というアドバイスをもらったのだけど、それが自分の言葉で実感を持てるようになった。システムを作る時には、そのシステムが解決したいビジネス上の課題を明確にすると良くて、それがユースケースを記述することなんだ、という紐付けが得られた。以前はユースケースを記述する時に粒度とかってケースバイケースだし難しいな〜〜って思ってたけど、目的が自分の中ではっきり理解出来た気がするから次はあまり迷わなそう。

この本のコンテキストは上流工程とかアーキテクトの単価とかそんな感じなので、ぼくたちの Web サービス開発にはこの本で得られた知見は直接そのまま持ち込めない。これから自分の開発に持ち込んで練り練りして昇華するのが楽しみ。

以上レポっす。

memo

• dyna book 構想: メインフレームとかしかなかった時代に、アラン・ケイが個人のエンパワメントをするようなコンピュータを考えて実現した
• アーキテクチャ: インフラの上にアプリケーション、アプリケーションの上にはソリューション、ソリューションの上にはビジネスがある
• 主要なほうがインターフェイスを提供する。例えばドメインロジックと物理層であればドメインロジックのほうが主要。ステレオシステムとマイク/スピーカーの例だとステレオシステムが主要。コンセントとステレオシステムの例だとコンセントが主要。
• 普通のアプリケーションアーキテクチャはロジックような内部は関心外。でも著者は踏み込んでアプリケーションアーキテクチャのために改善していくべきだと考えている。
• アーキテクチャの役割
  • システムの理解を助けなければならない
  • 組織の構造に影響を与えなければならない
  • 将来の見通しを良くしなければならない
  • ソースコードの実装ルールを提供しなければならない
  • システムの品質を実現しなければならない
• 品質とは: システム品質とビジネス品質、アーキテクチャ品質 (p59)
• 要件定義は品質目標も達成しなければならない (まぁこのへんはわりとやってる感覚あるな...)