LoginSignup
79
79
@e99h2121(Nobuko YAMADA)

「ソフトウェアアーキテクチャの基礎」を読んだので、その要点

Last updated at Posted at 2022-03-28

ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ | Mark Richards, Neal Ford, 島田 浩二 |本 | 通販 | Amazon

を読み直したのでその読書感想文です。「読み直した」というのは、2021年よりありがたくもこの本の査読に参加させていただいたからであります。

感想

  • 「基礎」という言葉の通り教科書的にアーキテクトのお仕事が学べる本。
  • 「パターン」とそれぞれの特性などが分かる。何度も読み直したい。
  • 「既にアーキテクトである人や駆け出しのアーキテクトに向けて、ソフトウェアの構造からソフトスキルに至るまで、ソフトウェアアーキテクチャとそのさまざまな側面を提供したい」との通り、とりわけ「ソフトスキル」という対人のものも結局はスキルなのだよなと気付く。
  • 査読は大変楽しかった！！！

要点

はじめに：公理を疑う

公理
確立され、一般に受け入れられているか、または自明の真実とみなされている言説、命題

本書を読んだからといって、一晩でソフトウェアアーキテクトになれるわけではない。ソフトウェアアーキテクトというのは、多くの側面を持つ曖昧な分野だからだ。私たちは本書で、既にアーキテクトである人や駆け出しのアーキテクトに向けて、ソフトウェアの構造からソフトスキルに至るまで、ソフトウェアアーキテクチャとそのさまざまな側面を提供したいと考えている。

本書では、よく知られているパターンを網羅する一方で、過去の教訓やツール、エンジニアリングプラクティスなどを参考に、新しいアプローチを取る。

1章　イントロダクション

  • ソフトウェアアーキテクチャの定義
  • アーキテクトへの期待
    • アーキテクチャ決定を下す
    • アーキテクチャを継続的に分析する
    • 最新のトレンドを把握し続ける
    • 決定の順守を徹底する
    • 多様なものに触れ、経験している
    • 事業ドメインの知識を持っている
    • 対人スキルを持っている
    • 政治を理解し、かじ取りする
  • アーキテクチャと交わるもの
  • ソフトウェアアーキテクチャの法則
    • ソフトウェアアーキテクチャはトレードオフがすべてだ。
    • 「どうやって」よりも「なぜ」の方がずっと重要だ。

第I部　基礎

2章　アーキテクチャ思考

  • アーキテクチャと設計
  • 技術的な幅
    • 個人の中にある知識は、すべて「わかっていること」と「わかっていないとわかっていること」と「わかっていないとわかっていないこと」の3つに分類できる。
  • トレードオフを分析する
  • ビジネスドライバーを理解する
  • アーキテクティングとコーディングのバランスを取る

3章　モジュール性

  • 定義
  • モジュール性の計測
  • モジュールからコンポーネントへ

4章　アーキテクチャ特性

  • アーキテクチャ特性の（部分的な）リスト
    • ドメインに依らない、設計に関する考慮事項を明らかにするもの
    • 設計の構造的な側面に影響を与えるもの
    • アプリケーションの成功に不可欠か重要なもの
  • トレードオフと少なくとも最悪でないアーキテクチャ
    • 決して最善のアーキテクチャを狙ってはいけない。むしろ、少なくとも最悪でないアーキテクチャを狙おう。

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

6章　アーキテクチャ特性の計測と統制

7章　アーキテクチャ特性のスコープ

8章　コンポーネントベース思考

  • コンポーネントの分類
  • アーキテクトの役割
  • 開発者の役割
  • コンポーネントを識別する流れ
  • コンポーネントの粒度
  • コンポーネント設計
  • 事例：「Going、Going、Gone」におけるコンポーネントの発見
  • アーキテクチャ量子再び：モノリシックアーキテクチャと分散アーキテクチャの選択

第II部　アーキテクチャスタイル

9章　基礎

  • 基礎的なパターン
  • モノリシックアーキテクチャと分散アーキテクチャ
    • https://microservices.io/
    • 誤信1：ネットワークは信頼できる
    • 誤信2：レイテンシーがゼロ
    • 誤信3：帯域幅は無限
    • 誤信4：ネットワークは安全
    • 誤信5：トポロジーは決して変化しない
    • 誤信6：管理者は一人だけ
    • 誤信7：転送コストはゼロ
    • 誤信8：ネットワークは均一
    • 分散コンピューティングにおけるその他の考慮事項

10章　レイヤードアーキテクチャ

  • 層の分離
  • レイヤーの追加
  • その他の考慮事項
  • このアーキテクチャスタイルを採用する理由
    • レイヤードアーキテクチャは、小規模でシンプルなアプリケーションやWebサイトに適している
  • アーキテクチャ特性の評価

11章　パイプラインアーキテクチャ

  • トポロジー
    • パイプ
    • フィルター
  • 事例
  • アーキテクチャ特性の評価

12章　マイクロカーネルアーキテクチャ

  • トポロジー
    • コアシステム
    • プラグインコンポーネント
  • レジストリ
  • コントラクト
  • 事例とユースケース
  • アーキテクチャ特性の評価

13章　サービスベースアーキテクチャ

  • サービスの設計と粒度
  • データベース分割
  • アーキテクチャ例
  • アーキテクチャ特性の評価
  • このアーキテクチャスタイルがふさわしいとき

14章　イベント駆動アーキテクチャ

  • トポロジー
  • ブローカー
  • メディエーター
  • 非同期の能力
  • エラー処理
  • データロスの防止
  • ブロードキャスト能力
  • リクエスト・リプライ
  • リクエストベースとイベントベースの間を取る
  • ハイブリッドなイベント駆動アーキテクチャ
  • アーキテクチャ特性の評価

15章　スペースベースアーキテクチャ

  • 一般的なトポロジー
    • 処理ユニット
    • 仮想ミドルウェア
    • データポンプ
    • データライター
    • データリーダー
  • データ衝突
  • クラウドとオンプレミス
  • レプリケーションキャッシュと分散キャッシュ
  • ニアキャッシュの考慮
  • 実装例
    • コンサートチケット販売システム
    • オンラインオークションシステム
  • アーキテクチャ特性の評価

16章　オーケストレーション駆動サービス指向アーキテクチャ

  • 歴史と哲学
  • トポロジー
  • 分類
    • ビジネスサービス
    • エンタープライズサービス
    • アプリケーションサービス
    • インフラストラクチャサービス
    • オーケストレーションエンジン
    • メッセージフロー
  • 再利用...と結合
  • アーキテクチャ特性の評価

17章　マイクロサービスアーキテクチャ

  • 歴史
  • トポロジー
  • 分散
  • 境界づけられたコンテキスト
    • 粒度
    • データ分離
  • API層
  • 運用面での再利用
  • フロントエンド
  • 通信
    • コレオグラフィとオーケストレーション
    • トランザクションとサーガ
  • アーキテクチャ特性の評価
  • 参考文献

18章　適切なアーキテクチャスタイルを選ぶ

  • アーキテクチャにおけるトレンドの変遷
    • 好ましいアーキテクチャスタイルは、さまざまな要因によって時代とともに変化していく
  • 判断基準
    • ドメイン
    • 構造に影響を与えるアーキテクチャ特性
    • データアーキテクチャ
    • 組織的な要因
    • プロセス、チーム、および運用上の関心事に関する知識
    • ドメイン／アーキテクチャの同型性
  • モノリスの事例：シリコンサンドイッチ
    • モジュラーモノリス
    • マイクロカーネル
  • 分散型のケーススタディ：Going、Going、Gone

第III部　テクニックとソフトスキル

19章　アーキテクチャ決定

20章　アーキテクチャ上のリスクを分析する

  • リスクマトリックス
  • リスクアセスメント
  • リスクストーミング
  • ユーザーストーリーリスク分析
  • リスクストーミング例
    • 可用性
    • 弾力性
    • セキュリティ

21章　アーキテクチャの図解やプレゼンテーション

  • 図解
  • プレゼンテーション
    • 時間を操る
    • 段階的な構築
    • インフォデッキとプレゼンテーション
    • スライドは物語の半分
    • 不可視化

22章　効果的なチームにする

  • チーム境界
  • アーキテクトのパーソナリティ
  • どうやって管理する？
  • チームの警告サイン
  • チェックリストの活用
  • ガイダンスの提供
  • 開発チームを効果的にするのは大変な作業だ。これには多くの経験と実践、そして強力なピープルスキルも必要
  • とはいえ、エラスティックリーダーシップ、チェックリストの活用、設計指針の効果的な伝達によるガイダンスの提供といったシンプルなテクニックは、実に有効で、開発チームがよりスマート、より効果的に動けるようになるために有効であることが証明されている。

23章　交渉とリーダーシップのスキル

  • 交渉とファシリテーション
  • リーダーとしてのソフトウェアアーキテクト
    • アーキテクチャの4つのC
    • プラグマティックでありながらもビジョナリーであること
      • 現実的であるとは、アーキテクチャのソリューションを作成する際に、次のような要素や制約をすべて考慮に入れるということを意味する。
        • 予算上の制約などコストベースの要因
        • 時間的な制約などの時間的な要因
        • 開発チームのスキルセットとスキルレベル
        • アーキテクチャ決定に関連したトレードオフと意味合い
        • 提案されたアーキテクチャ設計やソリューションの技術的な制限事項
    • 手本を示してチームをリードする
      • 多くの人は、技術的な問題を解決するために必要なのは技術的な知識であり、ピープルスキルは関係ないと考えている。技術的な知識を持つことは確かに問題を解決するために必要だが全体的な方程式の一部に過ぎない。たとえば、アーキテクトが開発者チームとミーティングを行い問題を解決しようとしているとする。開発者の一人がある提案をしたところ、アーキテクトは「それは馬鹿げたアイデアだ」と答えた。するとその開発者がそれ以上の提案をしないだけでなく、他の開発者も何も言わなくなってしまう。この場合アーキテクトの振る舞いは、チーム全体が解決策について協力することを事実上遮断してしまっている。
      • ジェラルド・ワインバーグ - Wikipedia
    • 開発チームに溶け込む

24章　キャリアパスを開く

  • 20分ルール
  • パーソナルレーダーの開発
  • ソーシャルメディアの使用

ほか参考記事

入門ソフトウェアアーキテクチャ4種 - Qiita

はじまり

で、こんな面白い本を先行して読ませていただいた。非常に嬉しかったです。

島田さん https://twitter.com/snoozer05 に感謝とともに書籍に興味を持つ方が増えたらなと感じます。

以上です～

79
79
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
79
79