Design It! プログラマーのためのアーキテクティング入門

https://www.oreilly.co.jp/books/9784873118956/
Amazon


全体レビュー

設計を行うためにどのようなことを考えるべきかを書いた本。最初で全体的な流れを説明し、後半で個別の手法について網羅的に述べている。

俯瞰した視点と、設計のための道具を知ることができると思う、コンパクトに全体像をつかめる本はあまり無く、その点でも良い本。

詳しい道具の使い方はこの本の範疇外ではあるが道筋がわかるというのが助かる。

各章紹介

目次は上のリンク先にある。内容的には以下のようになる。

  • 1 ソフトウェアアーキテクトとは
    • 「望まれる品質特性やその他の特性を促進するためにソフトウェアをどう構築するかということに対する、重要な設計判断が集まったもの」(p.8)
    • ビジネス、技術、ユーザー、それぞれに責任を持つ
    • エンジニアリングの立場から問題を定義し、システムを構築する
    • 品質特性のトレードオフの決定、技術的負債の管理、チームスキルの向上
    • プログラマーからソフトウェアアーキテクトになるために、プロダクトポートフォリオを作成してみよう
      • ビジネス目標、ステークホルダーの書き出し
      • どんな技術に取り組んだか
      • 最大のリスクと克服方法
      • やり直すならどこか
    • ソフトウェアアーキテクトによりもたらすこと
      • 大きい問題を小さく管理しやすく
      • 人々の協働の仕方を示す
      • 複雑な問題に対するための語彙の提供
      • 機能以外にも目を向ける
      • コストのかかる間違いを避ける
      • 変化に柔軟に対応する
  • 2 デザイン思考
    • 問題をどう理解し取り組んでいくかについて
  • 3 デザイン戦略
    • 事前の設計が全体のコストを下げるのにいかに重要かについて
  • 4 ステークホルダー
    • 誰と会話すべきか発見し、ビジネス目標を定義することについて
  • 5 要件の掘り下げ
    • 技術的要件とビジネス要件について、分類し定義する
  • 6 アーキテクチャを選ぶ
    • あー来てきちゃの全体構造を決定するために、要素とその役割を探求する
    • 選択肢に対して品質特性を考え評価する
    • 設計判断のタイミングについて
  • 7 設計パターン紹介
    • レイヤー、パイプ、pubsubなどのパターン紹介
    • なお何も考えられていない状態は「巨大な泥団子パターン」と呼ばれる
  • 8 モデル
    • 概念や規則のモデル化
    • 矛盾を調整し、良い名前をつけ、ドメインを抽出する
  • 9 話の進め方
    • アーキテクチャ設計に適切な人に参加してもらうことで、設計判断に対する合意形成をし、チームコミュニケーションを改善する
    • ここでの話の進め方について
  • 10 図による可視化
    • 図にした上で、どのような改善をするか
    • パターンを際立たせる
  • 11 アーキテクチャの記述方法
    • 必要な共有対象に対して必要なドキュメントを作る、管理する
    • 選ばなかった内容も記述する
  • 12 アーキテクチャの評価
    • 評価方法について
    • 良い質問をする、評価レビュー方法、課題発
    • 形式的な手続きのいらない方法からはじめる
  • 13 チームの強化
    • 設計権限の移譲の意味
    • 設計権限の移譲までの道のりとその後
  • 14 問題発見手法紹介
    • 問題を発見し理解するための各種手法について紹介
  • 15 問題解決手法紹介
    • 解決策を見つけたり、他の選択肢を選べるようにする
  • 16 設計理解のための手法紹介
    • コンテキスト図やシーケンス図を含む、可視化と理解の手法について
  • 17 設計の問題点解決のための手法紹介
    • 評価では、設計を批評的に分析して、ニーズを満たしているかを判断する
    • 評価は継続的な活動で、最後にだけやるものではない
    • 設計の評価手法について