【技術本】ソフトウェアアーキテクチャの基礎
【技術本】ソフトウェアアーキテクチャの基礎
https://amzn.to/3GEN80K
【技術本】ソフトウェアアーキテクチャの基礎
へポスト
ソフトウェアアーキテクトとはどういう役割か、どうあるべきかを記した著作。
ソフトウェアアーキテクトは、ソフトウェアーキテクチャの技術的な側面を理解するだけではなく、様々なステークホルダに自身が選定したアーキテクチャを効果的に伝えるのに必要な主要なコミュニケーションスキルとソフトスキルも備えていなければならない。なぜならば、アーキテクチャの提案をステークホルダに説明するときには常に異議が唱えられるためだ。そのため、自己で選定するアーキテクチャの引き出し、リスク分析技術など技術的内容は当然、企業の政治的状況までを理解し、効果的にステークホルダを説得しその状況を切り抜ける必要がある。さらには、決定したソフトウェアアーキテクチャを開発チームと共有し、リーダシップ性を発揮して効果的なチーム作りを導くスキルも求められている。
責任のロールの粒度は多少異なるが、情報処理技術者試験でのシステムアーキテクトの立場の人が一番役割として近いのではないだろうか。プロジェクトや規模によっては、リードプログラマ、メインプログラマ（設計も兼ねている）などがその役割を担うと考えられる。そういった立場の人がソフトウェアアーキテクチャの大枠の技術や、広義でもあるコミュニケーション、交渉、折衝スキルの過不足点を洗い直すのに価値が出てくる著作だと感じた。
以下気になった内容メモ
---------
●１章：イントロダクション
ソフトウェアアーキテクチャ：時代と共に変化してきている
昔はソフトウェアは一度実装すると変更は難しい定義だったが、今はそうではない
＞マイクロサービスなどの台頭
マイクロサービス：それぞれのサービスに専用のDBを持たせて、分離された独自のマシンで動かす
昔はライセンスなどで高額で実現は難しかったが、オープンソースの台頭で実現
アーキテクトへの期待
・アーキテクチャ決定を下す
・アーキテクチャを継続的に分析
・最新のトレンドを把握し続ける
・決定の順守を徹底
・多様なものに触れ経験している
・事業ドメインの知識を持っている
・対人スキルを持っている
・政治を理解しかじとりする
プロセスとエンジニアリングプラクティス
プロセス：チーム形成や管理、ミーティングの進め方、ワークフローの整理の仕方
＞人がどのように組織化され、どのように相互作用するかのメカニズム
エンジニアリングプラクティス：プロセスに依存しない手法
＞継続的イテレーションなど
XP:テストの数が多いほど品質が高まるという相関関係から、テストに対するアプローチを極限まで重視。
テストファーストで開発を行う。
イテレーティブなプロセスの方がソフトウェアアーキテクチャの性質に適している
＞アジャイル開発
-----
●第一部：基礎
●２章：アーキテクチャ思考
アーキテクトと開発チームに強い双方向の関係を気づく必要がある
従来は、アーキテクト＞開発者と一方通行
・技術的な幅
アーキテクト：技術的な幅
開発者：技術的な深さ
・トレードオフを分析する
ソフトウェアアーキテクチャは全てがトレードオフ
・ビジネスドライバーを理解する
・アーキテクティングとコーディングのバランスを取る
概念実証（PoC)を活用
●３章 モジュール性
モジュール性の計測
・凝集度：モジュールの要素がどの程度そのモジュールに収まっているか
フィールドを介して結合されていないメソッドの総和
＞フィールド変数が各メソッドで流用されていると凝集度が高い
逆にフィールドが他のメソッドに影響ない場合は、そのフィールドとそれを使うメソッドは別クラスにリファクタリングできる。
・結合度：
求心性結合：コンポーネント、クラス、関数などに外部から入力される接続数を計測
延伸性結合：コンポーネント、クラス、関数などに出力する接続数を計測
・コナーセンス：
静的なコナーセンス
動的なコナーセンス
●４章 アーキテクチャ特性
アーキテクチャ特性とは以下の3つの基準を満たすもの
・ドメインに依らない、設計に関する考慮事項を明らかにするもの
・設計の構造的な側面に影響を与えるもの
・アプリケーションの成功に不可欠な重要なもの
アーキテクチャをできるだけイテレーティブに設計するのがベスト
●５章 アーキテクチャの特性を明らかにする
全てのアーキテクチャ特性をサポートする汎用アーキテクチャの設計はアンチパターン
>サポート数が増えるごとにシステムが複雑になっていく
設計をシンプルに保つのが大事
暗黙的なアーキテクチャ特性を見極める必要がある。
スケーラビリティだけでなく、バーストアクセスに耐える必要があるかの検討
＞ホテル予約システムと、コンサート予約システムの違い
暗黙特性：可用性、信頼性、セキュリティ、カスタマイズ性
●６章 アーキテクチャ特性の計測と統制
アーキテクチャ適用度関数でコードを評価
・ルートの長さを評価
・コストを最小限にすることを評価
・総移動時間の短縮を最適化したことを評価
進化的アーキテクチャでは、この概念を借用してアーキテクチャ適用関数を定義
●７章 アーキテクチャ特性のスコープ
コナーセンス：システム全体の正しさを維持するため、あるコンポーネントの変更が別の
コンポーネントの変更を必要とする場合、2つのコンポーネントはコーナセント（接続）されている
静的コナーセンス：静的コード解析によって発見可能
動的コナーセンス：実行時の振るまいで発見可能
・同期的
・非同期的
凝集性：含まれるコードが目的に沿ってどれだけ統一されているか
例：プロパティ、メソッドが全てCustomerエンティティに関連するものなど
＞高い凝集性
●８章 コンポーネントベース思考
モジュールが物理的にパッケージ化されたもの：コンポーネント
>Javaのjarファイル, Rubyのgem, .NETのdll
アーキテクチャにおける最上位分割
・技術による分割
・ドメインによる分割:マイクロサービスアーキテクチャ
-----
●第２部
アーキテクチャスタイル
●９章 基礎
・ユニタリーアーキテクチャ
一つのマシン上で完結している
・クライアント／サーバ
デスクトップ＋データベースサーバ：リッチクライアント
ブラウザ＋Webサーバ
３層アーキテクチャ
モノリシックアーキテクチャと分散アーキテクチャ
・モノリシック（全てのコードが単一のデプロイメントユニットで構成）
レイヤードアーキテクチャ
パイプラインアーキテクチャ
マイクロカーネルアーキテクチャ
・分散（リモートアクセスプロトコルを介して接続された複数のデプロイメントユニット
で構成）
サービスベースアーキテクチャ
イベント駆動アーキテクチャ
スペースベースアーキテクチャ
サービス指向アーキテクチャ
マイクロサービスアーキテクチャ
ネットワーク
・ネットワーク通信は信頼できない
・ネットワークはレイテンシは０でない
・帯域幅は無限でない
・ネットワークは安全でない：悪意あるクライアントの存在
・トポロジーは変化する
・転送コストはゼロでない
・ネットワークは均一でない
●１０章 レイヤードアーキテクチャ
n層アーキテクチャとして知られている。
最も一般的なアーキテクチャスタイルの一つ
トポロジ
論理的な水平方向のレイヤーとして編成
一般的な構成：プレゼン層、ビジネス層、永続化層、データベース層
関心ごとの分離の概念
層の分離
・閉鎖レイヤー：層をスキップできずに直下の層を経由しなければならない
・解放レイヤー：
特性
コスト、シンプルさが突出している
●１１章 パイプラインアーキテクチャ
Unixターミナルシェル言語の背後にある基本原則にあるアーキテクチャ
例：コマンド ps -ef | grep hoge | sort -f | more
トポロジ
パイプとフィルタから構成される
・パイプ：フィルター間の通信チャンネルを形成
・フィルター：自己完結型で他のフィルターとは独立している
プロデューサー：処理の開始地点、出力のみ
トランスフォーマー：入力を受け、データの一部または全部を改変し出力パイプに送る
テスター：入力を受け付け、1つ以上の基準について検査し、オプションで検査に基づく出力を生成
コンシューマー：パイプラインフロー終了点
特性
コスト、シンプルさが突出している
●１２章 マイクロカーネルアーキテクチャ
製品ベースのアプリケーションにうまくフィットしている
カスマムビジネスアプリケーションでも広く使用されている
トポロジ
コアシステムとプラグインの2つのコンポーネントで構成
基本的なコアシステムと、独立したプラグインコンポーネントと別れている
アプリ機能やカスタム処理ロジックの拡張性、適応性、分離性を実現
例：Eclipse IDEとプラグイン
・コアシステム：システムを実行するのに必要な最低限の機能
・プラグインコンポーネント：コアシステムを強化、拡張する特殊な処理や機能追加など
・レジストリ：利用可能なプラグインモジュールやその入手方法の詳細情報を管理
特性
コスト、シンプルさが突出
●１３章 サービスベースアーキテクチャ
マイクロサービスアーキテクチャのハイブリッド
最も実用的なアーキテクチャスタイルの一つ
トポロジ
分散型のマクロなレイヤード構造
個別にデプロイされたUI、個別にデプロイされた粒度の粗いリモートサービス、モノリシ
ック(一枚岩)なデータベース
UIの背後に、複数のレイヤードアーキテクチャがあり、それらがモノリシックのDBを参照
している
トポロジーの種類
ユーザインタフェースを分割して、その背後のレイヤードアーキテクチャ(ドメインサービス)を分けてもいいし、一つのユーザインタフェースごとにレイヤードアーキテクチャを対応させてもいい
DBにおいても、特定のレイヤーおアーキテクチャに対応したDBを複数に分けてもいい
ユーザインタフェースとドメインサービスの間にAPI層（プロキシ、またはゲートウェイ）を追加してもよい
各ドメインサービス：APIファサード層、ビジネス層、永続化層などで構成（技術分割）
または、APIファサード層の下をドメイン分割により、複数のコンポーネントを参照する構成
特性
デプロイ容易性、耐障害性、モジュール性、コスト、信頼性、テスト容易性などが突出
●１４章 イベント駆動アーキテクチャ
分散非同期型のアーキテクチャ
小規模、大規模なアプリケーションに用いることが可能
イベント駆動アーキテクチャは非同期にイベントを受信して処理する、分離されたイベント処理コンポーネントで構成
単体でアーキテクチャとして活用できるし、他のアーキテクチャ（イベント駆動マイクロサービスアーキテクチャ）などに組み込むこともできる。
トポロジ
ブローカーとメディエーターという2つの主要なトポロジー
・ブローカー：イベント処理に対して高度な応答性と動的な制御が必要な場合に使用
軽量メッセージブローカー（RabbitMQ,AtiveMQ..etc)を介して、チェーン上のブロードキャスト方式でイベント処理コンポーネントに分散
・開始イベント：イベントフローを開始する最初の「イベント」のこと
・イベントブローカー：開始イベントを受け取ると呼び出される
・イベントプロセッサー：単一のイベントプロセッサーがイベントブローカーから開始イベントを受け入れ、そのイベント処理を開始する
・処理イベント：イベントプロセッサーで作成される「イベント」。何をしたかの通知。別のイベントブローカーに渡されたりもする
・メディエーター：イベント処理のワークフロー処理が必要な場合に使用
ブローカートポロジのいくつかの欠点を解消する
イベントメディエーターは、複数のイベントプロセッサーの調整を必要とするイベントを開始するためのワークフローを管理・制御する
・開始イベント
・イベントキュー：開始イベント用のキュー
・イベントメディエーター：キューからの開始イベントを受け取り、対応する処理イベントを生成して、専用のイベントチャンネルに送信
・イベントチャンネル
・イベントプロセッサー：専用のイベントチャンネルで待ち受け、イベントを処理し、通常はメディエーターに自分の作業が完了したことを返信
データロスの問題：非同期メッセージ伝達間のシステムクラッシュなどが原因
・インメモリにメッセージを保存するだけでなく、何らかのデータストア（ファイルシステムやDBなど）にメッセージを永続化する。そうすればメッセージブローカーが落ちた場合でも、復旧後にメッセージを処理できる。
・メッセージが永続化されたことをブローカーが確認するまで、メッセージプロデューサーがブロック待ちをする
上記2つのテクニックで、イベントプロデューサーとキューの間でメッセージが失われることはない
キューからメッセージを取得後、そのイベントをする前にイベントプロセッサーがクラッシュ：クライアント応答モードと呼ばれるメッセージングのテクニックで解決できる
＊キューにメッセージを残しつつ、クライアントIDをメッセージに付けることで、他のコンシューマがメッセージを読めないようにする。
特性
進化性、耐障害性、パフォーマンス、スケーラビリティで突出
●１５章 スペースベースアーキテクチャ
トポロジ
複数の並列プロセッサーが共有メモリを介して通信する技術
高い弾力性、パフォーマンスは、DBからレプリケートされたインメモリデータグリッドを活用して実現
処理ユニットごとにアプリケーションのデータはインメモリでメモリ内に保持され、全てのアクティブな処理ユニット間でレプリケートされる。処理ユニットは、データを更新すると。非同期にデータベースに送信。
負荷状況に応じて処理ユニット単位でスケール
・処理ユニット：Webベースのコンポーネントやバックエンドのビジネスロジッックが含まれる
特性
弾力性、パフォーマンス、スケーラビリティで突出
●１６章 オーケストレーション駆動サービス指向アーキテクチャ
●１７章 マイクロサービスアーキテクチャ
トポロジー
ひとつのAPIレイヤーの背後に、APIレイヤーの種類ごとにデータベースを持ったサービス（モジュール群）を持つ。
各自のサービスは独自のプロセスで実行される分散アーキテクチャを形成する
クラウドリソースとコンテナ技術により、各ドメインが独自のインフラをもてるようになった
パフォーマンス：分散型の性質がもたらす負の副作用がある。ネットワーク呼び出しは、メソッド呼び出しより時間がかかる。各エンドポイントでのデータ検証で処理時間がかかるなど。＞サービス境界を超えたトランザクションの使用を避けるのがよい
特性
弾力性、進化性、モジュール性、スケーラビリティで突出
＊パフォーマンスはある程度犠牲になる
●１８章 適切なアーキテクチャスタイルを選ぶ
新しいアーキテクチャデザインには、過去のアーキテクチャスタイルの欠点が反映される
判断基準
・ドメイン：設計するドメインの主要な側面の理解
・構造に影響を与えるアーキテクチャ特性
・データアーキテクチャ
・組織的な要因
・プロセス、チーム、および運用上の関心ごとに関する知識
・ドメイン／アーキテクチャの同型性
・モノリスか分散か
・データをどこに書くべきか
・サービス間の通信スタイルは、同期型か非同期型か
-----
●第３部
テクニックとソフトスキル
有能なソフトウェアアーキテクト
ソフトウェアーキテクチャの技術的な側面を理解するだけでは足りない
アーキテクトとして考え、開発チームを導き、様々なステークホルダにアーキテクチャを効果的に伝えるのに必要な主要なテクニックとソフトスキルも備えていなければならない
●１９章 アーキテクチャの決定
アンチパターン
・資産防御アンチパターン：選択を恐れてアーキテクチャ決定を先延ばししてしまうパターン
・グランドホッグデータアンチパターン：ある決定が下された理由がわからずに、繰り返し何度も議論されてしまうパターン
・メール駆動アーキテクチャアンチパターン：人々がアーキテクチャ決定を見失ったり、忘れたり、決定されたことを知らないため、そのアーキテクチャ決定を実装できなくなってしまうパターン
アーキテクチャ上重要なものとは
・構造
・非機能特性
・依存関係
・インタフェース
・構築手法
上記に影響を与える決定の内容が重要なもの
アーキテクチャ決定を文書化する方法の一つ
・アーキテクチャデシジョンレコード：タイトル、ステータス、コンテキスト、決定、影響という5つの主要セクションから構成(コンプライアンス、備考も追加)
●２０章 アーキテクチャ上のリスクを分析する
リスクマトリックスの活用
リスクアセスメント構築にも利用できる
リスクストーミング
複数のアーキテクトの参加、シニア開発者やテックリードの参加
ユーザーストーリリスク分析
●２１章 アーキテクチャの図解やプレゼンテーション
図解標準：
・UML
・C4
・Archimate
プレゼンテーション
蜂の巣にされた死体アンチパターン：スライドが基本的に発表社のメモであり、全て人に見えるように投影されているアンチパターン。聞き手の大半はスライドが映るとそれらのメモを読んでしまい、そのあと発表社がその文章を読み上げるのを待つという耐えがたい経験となる
●２２章 効果的なチームにする
チーム境界
・境界がきついとフラストレーションが溜まる
・境界が緩いと混乱をまねく
・適切な境界は効果的なチームを作る
アーキテクトのパーソナリティ
・コントロールフリークアーキテクト
あらゆる詳細な側面までコントロールしようとする
・アームチェアーキテクト
アーキテクチャを作成する際に実装の詳細を考慮しなすぎる
・効果的なアーキテクト
管理
・チームの親しさ
・チームサイズ規模
・メンバの全体的な経験
・プロジェクトの複雑さ
・プロジェクトの期間
チームの警告サイン
・プロセスロス：人を増やすほどプロジェクトにかかる時間が増える
・多次元無知：内心で否定していることに対して、自分が何か見落としているのだろうと考え、全員が同意してしまう現象
・責任の分散
ガイダンスの提供
設計指針を用いてガイダンスを提供することで、チームを効果的にできる
●２３章 交渉のリーダシップのスキル
企業の政治的状況を理解し、その政治的な状況を切り抜けられなければならない
＞決定には異議が唱えられるため
ビジネスステークホルダーとの交渉
他のアーキテクトとの交渉
開発者との交渉
リーダーとしてのソフトウェアアーキテクト
・プラグマティックでありながらもビジョナリーであること
ビジョナリー：想像力や知恵をもって、未来を考えたり、計画したりすること
プラグマティック：机上の空論でなく、実勢に基づくやり方で現実的に物事に対処
●２４章 キャリアパスを開く
１日最低２０分を使って、未知の未知を既知の未知に昇華させる
ソーシャルメディアを活用し、アドバイスをもらえる尊敬できる技術者を見つける
●付録A 自己評価のためのチェックリスト
本文の各章ごとのキー項目の質問が複数用意されている
以上
へポスト
オススメ類似レビュー記事