5分で読む「ソフトウェアアーキテクチャの基礎」2章 アーキテクチャ思考 要約
はじめに
本稿は名著「ソフトウェアアーキテクチャの基礎」の要約である。読者が5分程度で本書のエッセンスを捉えられることを意識して書かれてある。
本書籍の感想文は他にもいくつか公開されているが、本稿は節単位で要約をしていったため、比較的その中でも解像度の高い内容になっていると思う。
本稿は2章の要約となっている。
途中、いくつか私の個人的なコメントも添えている（黄色い網掛けの箇所を参照）。
前後の投稿
更新について
週に1,2回ほどのペースで不定期に更新していく予定。
更新は@d5onodaでお伝えしていきます。もしよければフォローよろしくお願い致します。🙇♂️
本ABDへの参加の希望ありましたら、気軽にTwitterのDMにてお知らせ下さい！
要約の手順
- 前準備として、マインドマップで文章を階層化し整理する。
- マインドマップをもとに要約する。
第1部
2章 アーキテクチャ思考
アーキテクチャ思考は開発者の思考とは異なる。また「アーキテクチャについて考える」ことでもない。
以下の4つの側面がある。
- アーキテクチャを機能させるために、開発チームとうまく協同できること。
- ある程度深くて広い技術的知識を持っていること。
- ソリューションと技術のトレードオフができること。
- ビジネスを伸ばすために乗り越えねばならない要素とアーキテクチャの関連を知っていること。
2.1 アーキテクチャと設計
アーキテクチャと設計の違いをアーキテクトらしく考えるには。
- アーキテクチャと設計の違いを理解する。
- この2つがどのように結びついているのか、ビジネスや技術の問題に対するソリューションを形成するかを見極める。
従来
アーキテクトが担う従来の責務モデルを、開発者のそれと比較してみる。
| ロール | 責務モデル |
|---|---|
| アーキテクト | ビジネス要件の分析。 アーキテクチャ特性（-ility）の抽出と定義。 問題領域に適したアーキテクチャパターンやスタイルを選択。 コンポーネント構造を作る。 成果物を開発者に引き継ぐ。 |
| 開発者 | アーキテクトから成果物を引き継ぐ。 以下を開発しテストする。 ・クラス設計 ・UI ・ソースコード |
従来の問題
アーキテクト → 開発者 の一方通行のベクトルが、アーキテクチャに関するあらゆる問題を引き起こす。
- アーキテクトの意図が開発者に伝わらない
- 開発者の決定がアーキテクトへフィードバックされない
結果的に、アーキテクチャが意図していたように機能しなくなる。
従来の問題を解決するには
アーキテクトと開発者は双方向にフィードバックしあう。
- アーキテクト → 開発者 に働きかける。
- リーダーシップ
- メンタリング
- 開発者 → アーキテクト にフィードバック。
- 開発現場での決定事項
2.2 技術的な幅
求められる技術的詳細の範囲
- 開発者：技術的な深さ。
- アーキテクト：技術的な幅。
個人の中にある知識
| 分類 | 詳細 |
|---|---|
| わかっていること | 仕事で使用する技術 フレームワーク 言語 ツール etc... |
| わかってないと、わかっていること | 知っているだけで、専門知識がないもの |
| わかってないと、わかってないこと | 問題解決に最適でありながら、その存在をしらないもの もっとも大きな部分 |
開発者のキャリアのステージによって異なるもの
| キャリア | 分類の状態 |
|---|---|
| 初期（開発者） | ・「わかっていること」を伸ばすことに焦点を当てる。 ・「わかってないと、わかっていること」はつられて増えていく。 ・「わかってないと、わかってないこと」もつられて増えていく。 ・問題解決への重要度： 5つのソリューションを知っている < 1つのソリューションの専門家 |
| アーキテクト | ・「わかっていること」は特化する領域以外は減っていく。 ・「わかってないと、わかっていること」を増やすことに焦点を当てる。 ・「わかってないと、わかってないこと」もつられて増えていく。 ・問題解決への重要度： 5つのソリューションを知っている > 1つのソリューションの専門家 |
開発者からアーキテクトにクラスチェンジする時
- 発生する機能不全
- 様々な分野で専門性を維持しようとし続け、時間が足りずに失敗する。
- 時間とともに専門性が陳腐化するが、古い技術を最先端だと勘違いし続ける。
- 知識の習得方法を変える必要がある。
2.3 トレードオフを分析する
「アーキテクトらしく考える」とは
- 技術的かどうかに関わらず、あらゆるソリューションのトレードオフを見当する。
- 「アーキテクチャとは、Google検索で答えを見つけられないものだ。」
- どんなアーキテクチャにもメリットとデメリットがある。
- AAAとBBB、このケースではどちらがより重要か？
「トレードオフ」とはなにか
- 「アーキテクチャでは全てがトレードオフ」
- 「アーキテクチャには正解も不正解もない、あるのはトレードオフだけ」
- 「開発者は利点はわかっているが、トレードオフはわかっていない。アーキテクトはその両方を理解する必要がある。」
アーキテクチャのあらゆる問いに共通する答え
- 「それは場合による。」
- 答えは、以下の要素に依存する。
- デプロイ環境、ビジネスドライバー、企業文化、予算、期間、開発者のスキルセット、etc...
具体例
出品商品への入札オークションシステムを考える。
| プレーヤー | 説明 |
|---|---|
| bid producer | メインサービス。 入札時に入札情報を生成。 "bid capture"、"bid tracking"、"bid analytics" に入札情報を送信する。 |
| bid capture bid tracking bid analytics |
アプリケーションサービス。 "bid producer" から入札情報を受け取る。 |
問い
全てのアプリケーションサービスに bid producer が入札情報を送信したい。以下2つの方法のどちらが良いか。
1. サービス間通信にトピックを使用する
2. サービス間通信にキューを使用する
開発者の答え：1
理由：
- bid producer は1つのトピックだけに接続すれば良い。
- アプリケーションサービス "bid history" を増やしたとしても、"bid history" にトピックをサブスクライブさせればよく、既存システムに変更を加える必要はない。つまり、アプリケーションサービスの増減は、アプリケーションサービスだけで対応可能である。システム結合度は低い。
- 2の場合、アプリケーションサービス "bid history" を増やすとどうなるか。"bid history" 用の新しいキューが必要となる。
- メインサービス "bid producer" には新しいキューへの接続をするための修正が必要となる。つまり、アプリケーションサービスの増減ごとに、キューの増減とメインサービスの修正が発生する。
- システム結合度が高い。
「開発者はメリットはわかっているが、トレードオフはわかっていない。アーキテクトはその両方を理解する必要がある。」
アーキテクトの答え：2
理由：
- メリットだけではなく、デメリットも確認し、トレードオフで分析しているから。
- 1の方法では、誰でも入札情報にアクセスできてしまう。
- 2の方法では、キューに送られた入札情報は、そのメッセージを受け取った特定のコンシューマーからしかアクセスできない。仮に不正なサービスがキューをリッスンしたとして、対応するアプリケーションサービスが入札情報を受け取れず、管理者にデータロスの通知が飛ぶだろう。つまり1と比較して2は盗聴が困難となる。
- 1と比べて2のキュー形式は、それぞれのコンシューマーが必要な入札情報に対して個別のコントラクト（契約）を持つことが可能である。
- 1のトピック形式ではメッセージ数をうまく監視できないためにオートスケール能力を持てない。2のキュー形式であれば各キューを個別監視し、コンシューマーごとに自動ロードバランシングを行うことで、個別にオートスケールが可能である。
トピック形式のトレードオフ
| 得るもの | 失うもの |
|---|---|
| アーキテクチャ上の拡張性 | データアクセスとデータセキュリティの関心事 |
| サービスの分離 | それぞれ固有のコントラクト 監視とプログラムによるロードバランシング |
結論
ソフトウェアアーキテクチャではすべてがトレードオフである。どんなアーキテクチャにもメリットとデメリットがある。アーキテクトはトレードオフを分析し、「AAAとBBB、このケースではどちらがより重要か？」と問わなければならない。
2.4 ビジネスドライバーを理解する
「アーキテクトらしく考える」とは
- 必要なこと
- ある程度の事業ドメインの知識。
- 主要なビジネスステークホルダーとの協力的な関係。
- システムの成功に必要なビジネスドライバーを理解し、それらの要件をアーキテクチャ特性へと変換する。
2.5 アーキテクティングとコーディングのバランスを取る
アーキテクティングとコーディングバランスをどうとるか
著者の信念は、すべてのアーキテクトがコードを書き、一定のレベルの技術的な深さを維持できるべきである。
また、ヒントは「ボルトネックの罠」を避けることである。
ヒントは「ボルトネックの罠」を避けるには
問題
アーキテクトが、チームのクリティカルなコードの所有権を持っており、これがボトルネックとなってしまう。これは、アーキテクトがフルタイムの開発者でないことで生じる。
解決策
ボルトネックの罠を回避することである。
1つ目は、クリティカルなコードは開発チームに任せ、アーキテクトは少ないイテレーションで可能な開発のみに注力することである。これによるポジティブな効果としては以下がある。
- チームのボトルネックとならずにプロダクションコードの実務経験を積める。
- クリティカルなコードの開発は開発チームに任せれば、システムの難しい部分への理解が進む。
- 開発作業がアーキテクト&開発者の協同作業。開発チームの問題をアーキテクトが理解できる。
2つ目は、アーキテクトがコードを書けない場合に、アーキテクトが現場感を持ち続けられる方法である。
- 概念検証（PoC）を頻繁に行い、アーキテクチャ決定の検証をすること。具体的には、プロダクションレベルの品質のコードを書くことである。これには、使い捨てコードが他人に参照されるのを防ぐ、質の高いコードを書く練習ができるといった効果がある。
- 技術的負債やアーキテクチャのストーリーを引き受けることである。これは優先度が低いストーリーである。例えば、イテレーション内でバグ修正を行うなど。これによって開発チームに需要で機能的なストーリーに集中してもらう。
- 開発チームのルーティンワークを自動化し、CI/CDやIaC化で支援することである。
- コードレビューすることである。これにより、アーキテクトがメンタリングやコーチングの機会を得られ、ソースコードへの関与もできる。
本稿の終わりに
書籍の要約はまだまだ続きます。
更新は@d5onodaでお伝えしていきます。もしよければフォローよろしくお願い致します。🙇♂️
本ABDへの参加の希望ありましたら、気軽にTwitterのDMにてお知らせ下さい！
→ To be continued!
Discussion