ソフトウェアアーキテクチャの基礎の備忘録

はじめに

ソフトウェアアーキテクチャの基礎の備忘録

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

アーキテクトも結局はピープルスキルによって仕事の出来が変わってくる
技術的知識を持つことは必要であることに変わらないが、その知識を効果的にチーム（開発者やステークホルダー）に説明し理解・協力を承諾してもらう必要があるから

ピープルスキルの具体的なテクニック

• 会話の中で「検討してみた？」「はどうだろうか？」という言葉を活用する
  • 「しなければならない」と言った言葉は、意見を開発者に押し付けることになる＝コミュニケーションを本質的に遮断してしまう
• 交渉や会話の冒頭で相手の名前を呼ぶ
  • 人は名前を呼ばれることで、無意識に親近感が湧くものだから

技術的知識の習得テクニック(24章に記載があるが、こちらにまとめる)

• 朝の20分ルール
  • 仕事を開始する前（主にメールチェック前）の20分の利用
  • それ以外の時間帯は定期的に時間の確保が難しいものだから

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

• アーキテクトが開発チームを無視して、サイロ化された環境でアーキテクチャを作成している良くない現場あるあるがある
  • アーキテクトが開発チームを過度にコントロールしようとしてしまうパターン
  • アーキテクトの経験や知識不足から抽象度の高いアーキテクチャを提示してしまうパターン

またチーム規模が大きくなると、多元的無知や責任の分離が発生する

• 多元的無知
  内面では否定しているものに対して、自分が何かを見落としているのだろうと考え、全員が同意してしまう現象のこと
  心理的なバイアスによる影響なので、普段から否定的な意見に寛容な状態を作り出すのが大事
• 責任の分離
  誰が何のために何を担当しているのか混乱したり、物事が抜け落ちたりすること
  責任を意識できるサイズにチームを分割するのが良さそう

チェックリストはチームにカタを適用させるのに有用
しかし、なぜチェックリスト使うのか十分理解してないと使われなくなってしまう
チェックリストを使う背景を説明してもなお利用促進が進まない場合は、ホーソン効果(一度チェックリストが利用されたかを皆でチェックする。そうすることで次回から監視されていると思い利用するようになるというもの)を活用するのが良い

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

アーキテクトがアーキテクチャを説明する際のTipsがまとめられている

アーティファクトへの不合理な愛着

時間をかけて作成した成果物（アーティファクト）にアーキテクトは不合理な愛着を持つ習性がある
しかも、それは時間に比例して愛着は深くなるという比例関係がある
この観点から必要以上にアーティファクト生成に時間をかけないことが、アーキテクト側に必要なこと

クッキー型アンチパターン

プレゼン用のスライドに余計な装飾(出現、消失、移動などの動き)で埋め尽くすべきではない

蜂の巣にされた死体アンチパターン

スライドが発表者のメモになっている状態のもの
聞き手の大半はスライドの文字を追ってしまう習性がある
その後発表者の話を聞くと、既に読み込んで来た内容を説明され苦痛を感じてしまう

19章 アーキテクチャ決定

アーキテクチャ決定プロセスにおけるアンチパターン

1. 資産防御アンチパターン
   • 間違いを恐れて、アーキテクチャ決定を避ける or 先延ばしにする
   • 対策
     • 最終決定日まで、妥当であると判断できるまで情報を集める
     • 開発チームに協力を仰いで実現可能性の解像度を上げる
2. グラウンドホッグデー アンチパターン
   • アーキテクチャ決定したのにも関わらず、何度も議論が繰り返されること
   • 対策
     • 決定時に根拠を示さないことが原因
     • ここでいう根拠はビジネス的観点、技術的観点の２種類ありどちらも必須である
       • 例えばAngularからReact化したいと言った場合、技術的側面だけでなく、ビジネス的観点の説明の提示が必要
3. メール駆動アンチパターン
   • 決定を見失ったり、忘れたり、そもそも知らなかったりが発生すること
   • 対策
     • ADRを使って文書化(ADRの基本はP290の図と説明を参照)
       • メール本文に決定事項を添えても変更があったら気付けないでしょ？
     • 本当にアーキテクチャ決定に関心を持っている人に伝える

これらは1->2->3の順に表面化してくる

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

技術によって分割を重視したアーキテクチャ。その分離した技術が他のサービスから呼ばれるという構成。
P244の下図が示すように、外側の複数あるサービスはどれも顧客サービスを参照している。
顧客サービスを分離することで疎結合のような構造を取っており扱いやすいかと思いきや、顧客サービスを改修すると参照しているすべてのサービスに影響がでるという欠点を持つ。
このような顧客サービスを核(オーケストレーション)として設計されたアーキテクチャのことと理解。
一方で、評価はどれもいまいちで、アーキテクチャの選定でこれを選ぶことは否定的な文体のように感じられた。

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

一時的にトラフィックが急増するシステムに向いている（コンサートチケットやオークションなど）
データベースをスケールアウトさせようとしたり、スケーラビリティのないアーキテクチャにキャッシュを後付けしたりする前にこのアーキテクチャが適しているか確認すると良い
一方で、インメモリキャッシュを利用することから高コストにならざるを得ないことや、データロス防止やテスト容易性が低いなどの運用面での課題はある
また、馴染みがないのでアーキテクチャの中身がイメージしづらく理解しきれてないという別の課題もある
18章ではゲノム解析のような多数の離散的処理を必要するためスペースアキテクチャを推奨していた。

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

リクエストベース（同期）とイベント駆動アーキテクチャ（非同期）の比較

リクエストベースに勝る部分	トレードオフ
動的なユーザーコンテンツに対する応答性の向上	結果整合性のみをサポート
スケーラビリティ・弾力性の向上	処理フローの制御性の低下
アジリティとチェンジマネジメントの向上	イベントフローの結果に対する確実性の低下
適応性と拡張性の向上	テストやデバッグが難しい
充実した対応力とパフォーマンス
リアルタイムでの意思決定が可能になる
状況認識に対する反応の良さ

非同期通信によるアーキテクチャ上の特徴

非同期を利用することでシステム全体の応答性を向上させることができる一方で、エラー処理は複雑になってしまうため、課題となってしまう
エラー処理に対してはワークフローイベントパターンで複雑さを低減させている。
また、非同期通信がためにデータロス(メッセージが途中でドロップされたり、最終ゴールに到達しなかったりすること)が最大の懸念事項になる。
データロスに対しては、同期送信、クライアント応答モード、LPSといったテクニックを利用した対応を行うことで回避している。
一方で、テストやデバッグに関しては工夫が必要になる。

ワークフローイベントパターン

処理中にエラーが発生した場合、エラーをワークフロープロセッサーに移譲。
ワークフロープロセッサー内で原因を分析し、修正が可能であれば修正して送り返すし、だめだったら別のキュー(例えば、デッドレターキュー)に送る。

２種類のトポロジーがある

ブローカー

来たイベントを処理して次に流す。他のイベントの事を意識しないアーキテクチャーなので高いスループットが出せる。
出力に重きをおいている分エラー処理は弱い

メリット	デメリット
高度に分離されたイベントプロセッサー	ワークフローの制御
高いスケーラビリティ	エラー処理
高反応性	回復性
高パフォーマンス	再起動の能力
高耐障害性	データ不整合

メディエーター

ブローカートポロジーで考慮してない、ワークフロー制御することで、イベント状態を維持し、エラー処理、回復、再起動の管理ができるようになる。

メリット	デメリット
ワークフロー制御	イベントプロセッサー結合が強くなる
エラー処理	スケーラビリティの低下
回復性	パフォーマンス低下
再起動能力	耐障害性の低下
データ一貫性が高まる	複雑なワークフローのモデリング

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

現代において最も実用的なアーキテクチャの１つ。
分散アーキテクチャに分類されるが、マイクロサービスやイベント駆動のような複雑さはないことから人気の選択肢になっている。

トポロジー

基本構成は

• 個別にデプロイされたユーザーインターフェース
• 個別にデプロイされた粒度の粗いリモートサービス(通常ドメインサービスと呼ばれる)
  • ドメインサービスは一般的に粗い粒度
  • 平均的に4~12個のサービスからなる
• モリリシックなデータベース

からなる
亜種は色々ある

• P169にあるようにユーザーインターフェースを複数分割させるパターンや
• P170にあるようにデータベースを複数に分割させるパターンなどがある
• P171にあるようにユーザーインターフェースとサービスの間にリバースプロキシやゲートウェイを挟むこともある

ドメインサービスにおける設計パターン

• レイヤードアキテクチャによる技術による分割か、モジュラーモノリスのようなドメインによる分割がある
• サービスが4~12個とあることから、データベースの分割も可能だがテーブルスキーマの変更や管理にコストはそれなりに掛かる
  • P174のように各サービスで単一の共有エンティティオブジェクトを参照していると影響範囲の確認が大変
  • P175のようにすべてのサービスで使用されるcommonと各ドメインで利用するものを分けることで影響範囲を最小化させるのがよく利用される(論理的な分割と表現されている)

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

コアシステムが主役で、脇役がプラグインコンポーネントの構成
プラグインコンポーネントは脱着可能だが、必ずコアシステムを出発点とする必要がある
故にモノリシックなアーキテクチャになる
一般的な例でいうとJIRAやEclipsなどのIDEやChormeなどのWebブラウザがそう（プラグインを入れて、コア機能から呼び出す構成）
プラグインとして切り出すことで疎結合な設計を実現している
レイヤードアーキテクチャやパイプラインアーキテクチャと異なり、技術による分離もできるし、ドメインによる分割もできるという唯一のアーキテクチャスタイルを持つのが特徴

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

パイプラインアーキテクチャをすごく抽象化してイメージしやすくとしたらbashなどのフィルター毎に情報を加工していくアレ

tr -cs A-Za-z '\n' | tr A-Za-z | sort | uniq -c | sort -rn | sed ${1}

モノリシックなアーキテクチャの１つ
レイヤードアキテクチャと同じで、技術(フィルター)で分離された構造を持つ
パイプラインアーキテクチャにおける技術はフィルターのことで種類としては４種類ある

• プロデューサー: 処理の開始地点。出力のみ。
• テスター: 入力をうけて１つ以上の基準について検査し、オプションで検査に基づく出力を生成する(reduce関数のアレ)
• トランスフォーマー: 入力を受け、オプションでデータの一部または全部の変換を行い、せれを出力パイプに送る(map関数のアレ)
• コンシューマー: パイプラインフローの終了点。パイプランプロセスの最終結果をユーザーインターフェースに表示したり、データベースに永続化したり

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

各レイヤー毎に関心事が分離された技術によって分割されたアーキテクチャ。
そのため、開発者は特定の専門的な技術的知識を発揮し易い。
一方で、関心事を分散させている反面、全体的なアジリティの欠如が代償になる。

また、ドメインによって分割されたアーキテクチャとは対照的で、特定のビジネスドメインがアーキテクチャのすべての層に散らばってしまう。

8章からの引用として

• レイヤードアーキテクチャを使用する場合はコンウェイの法則の影響を受けやすい
  • （バックエンド開発者、DBA、プレゼンテーションを担うチームがそれぞれのレイヤーを担当する）
• 技術が各レイヤーを横断するフローを必要とする（例：カタログをチェックアウトするコードはすべてのレイヤーに現れる）

トポロジー

• レイヤードアーキテクチャ内のコンポーネントは論理的な水平方向のレイヤーとして編成される
• レイヤーの数や種類に制限は無いが、大抵は標準的なプレゼンテーション層、ビジネス層、永続化層、データベース層からなる

各レイヤーの役割

• プレゼンテーション層
  • ユーザーインターフェースとバックエンドとの通信ロジックに責任がある
  • 顧客データをどのように取得するかを知っている必要はない。情報を特定の形式で画面に表示するだけ
• ビジネス層
  • リクエストに関連した特定のビジネスルールの実行に責任がある
  • 永続化層からデータを取得し、そのデータに対してビジネスロジックを実行し、その情報をプレゼンテーション層に渡すだけ

閉鎖レイヤーと開放レイヤー

• 閉鎖レイヤー
  • リクエストがレイヤーを上から下へ移動していく際に、いずれのレイヤーもスキップせずに直下の層を経由していかなければならないアーキテクチャ
  • 閉鎖レイヤーによって層の分離が実現される
• 開放レイヤー
  • 直下の層を経由せずに住むレイヤー（例えば、プレゼンテーション層が直接データベース層にバイパスする）
  • アーキテクチャ上の管理と制御が困難になる

アーキテクチャシンクホールアンチパターン

各レイヤー内でビジネスロジックが実行されず、リクエストがパススルーされてレイヤー間を移動すること
要はプレゼンテーション層からビジネス層が呼ばれるが、ビジネス層では何もせず（集計や計算、ルール適用、変換など）データを戻す
これにより不要なオブジェクトのインスタンス化により、メモリ消費とパフォーマンスに負の影響を与えてしまう

9章 基礎

【巨大な泥団子】
行き当たりばったりで構造化された、ずんぐりとした、ずさんな、ダクトテープと鉄線、スパゲッティーコードのジャングルのこと
こうしたシステムには無秩序な成長の痕跡が見られ、さらに、都合よく修復が繰り返されている。
情報はシステムの遠く離れた要素間で乱雑に共有され、重要な情報の殆どすべてがグローバル化したり重複したりすることがよくある。
全体的な構造が十分に定義されてなかったために、そうなってしまったかもしれない。
あるいは、最初は定義されていたが、認識できないほどに侵食されてしまったのかもしれない。
アーキテクチャの感性を持つプログラマーであれば、こうした泥沼は敬遠する。
アーキテクチャに無頓着で、おそらく、破綻した堤防の穴を修復する日々のしごとの惰性に安住しているプログラマーだけが、このようなシステムに満足して取り組むのだ。

• モノリシック
  • レイヤードアーキテクチャ
  • パイプラインアーキテクチャ
  • マイクロカーネルアーキテクチャ
• 分散
  • イベント駆動アーキテクチャ
  • スペースベースアーキテクチャ
  • サービス指向アーキテクチャ
  • マイクロサービスアーキテクチャ

分散コンピューティングのつらみ

• ネットワークは信頼できるのは誤り
  • 分散アーキテクチャはすべてのサービス間通信がネットワークに依存することになるため、サービスBに全く問題が無かったとしても、ネットワークの問題でサービスAに到達できない場合が出てしまう
• レイテンシーがゼロは誤り
  • 分散アーキテクチャで、1リクエストあたりの平均レイテンシーが100ミリ秒だと仮定して、特定のビジネス機能を実行するために10回サービスを呼び出しする場合、リクエストに1000ミリが追加されることになる。1000ミリはレイテンシ無視できなくなるよね
  • 平均レイテンシーよりも95〜99パーセントタイルをチェックしていくのが大事
• 帯域幅は無限ではない
  • モノリシックではモノリス内部で完結するから意識あまりしないが、分散の場合サービス間の相互のトラフィックが発生し帯域を消費する
  • Privateなエンドポイントを作ったり、graphqlで不要なフィールドを取ってこないようにしたりすることで帯域へ逼迫を減らそう
• ネットワークは安全ではない
  • 分散サービス上のすべてのエンドポイントを保護する必要があり、モノリスに比べて飛躍的にセキュアの構成にするために考えることが増えがち
• ネットワークのトポロジーは変化する
  • ルーターやハブ、スイッチ、FWなど決して変化しないものだと考えがちだが決してそうではない
• ネットワーク管理者は1人じゃない
  • 1人の管理者とコミュニケーションを取れば良いと思いがちだが、分散アーキテクチャの数が増えれば増えるほど、管理者は増えるのが普通。そうなると問題が発生したときのコミュニケーションパスは増えるのも自明
• モノリスよりもコストかなり高くなる
  • それぞれのサービスを動かすためのサーバーやネットワークの構築が必要だから
• 分散ロギング
  • ログが分散されるので追跡が難しい。ツールを上手く使って集約しないいけないコストもある。
• 分散トランザクション
  • 結果整合性でしかデータを管理できない
  • トランザクションサーガなど分散トランザクションを管理する方法が必要
• チーム間でのコントラクト（契約）の調整コストが高い
  • サービスやシステムが複数のチームや部門に所有されることで調整が困難になりがち

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

コンポーネント ＝ モジュールが物理的にパッケージ化されたもの

コンポーネントにも分類(単純な既存コードのラッパーだったり、サブシステムレイヤーだったり、イベントプロセッサーだったり)がある

• アーキテクトはアーキテクチャを構成するコンポーネントを定義し、適切な分割をする役割を担う
  • TLや開発者との棲み分けとしては、クラスや関数の設計など実装ベースに関与しないことを推奨している（次世代のアーキテクトを育てるために）
    • 開発者もアーキテクトが設計したコンポーネントを完璧として捉えてはいけない（イテレーティブに改善し続けることで理想に近づいていくという考え方）
    • アーキテクトの最大の課題はコンポーネントの適切な粒度を発見することであり（これはイテレーティブなアプローチによって確度が高くなる）
  • 分割の具体例で言うと
    • レイヤードアーキテクチャ：プレゼンテーション、ビジネスルール、永続化といった技術的関心事で分割
    • モジュラーモノリス：ドメインやワークフローを中心にアーキテクチャを分割
      
  • 分割を助けてくれる手段
    • エンティティの罠に陥らない
      • マネージャーコンポーネント群を作って、安易にフレームワークとDB間のオブジェクトマッピングをしない
    • アクター／アクションアプローチ
      • アクターとアクションをマッピングするUMLを作るやつ
    • イベントストリーミング
      • DDDを出自としていて、マイクロサービスアーキテクチャの深掘りと相性が良い
    • ワークフローアプローチ
      • 主要なロールを明らかにして、そのロールが行うワークフローを決定し、アクティビティを中心にコンポーネントを構築していく
• 初期にモノリスか分散かを決めること（アーキテクチャスタイルを決めること）は非常に大事
  • そのために、アーキテクチャ特性のスコープと結合を分析する必要があり、その手段としてアーキテクチャ量子の数を使用するのが良い
    • システムが単一のアーキテクチャ量子で管理できるのであればモノリスアーキテクチャはメリットが大きい

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

【アーキテクチャ量子】とは
高度な機能的凝集性と同期的なコナーセンスを持つ、独立してデプロイ可能なアーティファクト

【コナーセンス】とは
システム全体的な正しさを維持するため、あるコンポーネントの変更が別のコンポーネントの変更を必要とする場合、２つのコンポーネントは接続(コナーセント)されている

運用特性を評価する場合に、コードベース外の依存コンポーネントについて考慮しないといけない。例えば、アーキテクトがどれだけ弾力性のあるコードベースの設計をしても、その特性にマッチしないデータベースを使用していたら運用特性はあげられないよね
こうした依存性の評価の要素を、アーキテクチャ量子と定義
アーキテクチャ量子自体はは依存関係の話なのでコナーセンスを深掘っていこう
コナーセンスには、静的・動的がある
静的はコード解析によって明らかにすることができ、動的は実行時に確認することができる依存関係(動的には更に、同期的・非同期的がある)

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

アーキテクチャ特性を計測するのは難しい
理由は、定義が現場によって異なるため(パフォーマンスはレイテンシーなのか処理の実行時間なのか)
また、意味合い自体が曖昧でそもそも認識がずれがちだったり、複合的な意味（アジリティはモジュール性、デプロイ容易性、テスト容易性を内包している）を持っていたりする

よって組織で具体的な定義に合意することが求められる

計測のための客観的定義の例として

• 運用面での計測のメトリクス例
  • コンテンツの初回イベント(First Contentful Paint)
    • ブラウザがコンテンツを描画し始め、ユーザーにページが読み込み中であるという最初のフィードバックがなされる時間
  • CPUの初回アイドル(First CPU Idle)
    • Webページにおけるメインスレッド処理が停止し、入力できるようになるまでかかった時間
• 構造面での計測

  • 循環的複雑度

    CC = エッジ数 - ノード数 + 2

    で表現される
    エッジとはif文のブロックの数で、ノードはif文の条件式の数
    以下の場合エッジ数が３でノード数が２になる

    if (num < 100) {
      return 0;
    } else if (num > 100 && num < 200) {
      return 1;
    } else {
      return 2;
    }
    

    循環的複雑度が高ければロジックとして複雑度は増し、モジュール性、テスト容易性が失われていくのは理解しやすい

  • テスト駆動開発は偶発的に循環的複雑度を低く抑えられる性質を持つ（テストを書いていく上で自然と複雑度を減らしていく動きが生まれる）

• プロセス面での計測
  • ソフトウエア開発プロセスに対する指標例
    • テスト容易性：カバレッジ
    • デプロイ容易性：デプロイ成功失敗率やデプロイ時実行時間

上述したように、アーキテクチャ特性を計測する仕組み自体の具体を学んだところで、では一体優先順位はどうしたらよいのか？（どれから着手すればよいのか？）という判断が必要になる
そこで、本書では進化的アーキテクチャの適応度関数という概念を紹介している

【アーキテクチャ適応度関数】
あるアーキテクチャ特性またはアーキテクチャ特性の組み合わせについて、客観的な整合性評価を行うための「何らかの仕組み」

何らかの仕組みとあるように
適応度関数は、メトリクスや監視、ユニットテスト、カオスエンジニアリングなどの既存の多くの検証方法をうまく活用して整合性評価につなげる
本書で上がっている具体例として

• コンポーネントの循環依存度の計測
• レイヤードアーキテクチャの統制度の計測
• Netflixにおけるカオスエンジニアリング
  などが紹介されていた

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

4章でアーキテクチャ特性の定義について学んだ。
5章ではそのアーキテクチャ特性、特に重要なアーキテクチャ特性をどう表面化させるかについて記載されている。

• ドメインの関心事を翻訳することで、アーキテクチャ特性を明らかにすることができる

  • アンチパターン：すべてのアーキテクチャ特性をサポートする汎用アーキテクチャの設計
  • アンチパターン：ステークホルダーに優先順値を付けてもらう
    • ステークホルダー全員が合意に至ることはない
  • 良いプラクティス：リストを作成し、最も重要な上位３つの特性を順位を付けずにステークホルダーに選んでもらう

• 要件からアーキテクチャ特性を抽出する

  • 経験が必要になり一筋縄ではいかない
  • アーキテクチャ・カタを使って練習することはできる

• 明示的アーキテクチャ特性: 必要な要件として仕様書に明記されているもの

• 暗黙的アーキテクチャ特性: 仕様書に明記されてはいないが設計に重要な側面を持つ特性

  • 可用性や信頼性、セキュリティなどはあって当たり前であるため、暗黙的に設計の要素として組み込まれている

4章 アーキテクチャ特性

アーキテクチャ特性とは

システムがサポートしなくてはならない 「 ~ility（〇〇性） 」 のこと

具体的には

• 可用性
• テスト容易性
• 信頼性
• 耐障害性
• 弾力性
• 回復性
• デプロイ容易性
• 学習容易性
• セキュリティ
• パフォーマンス
• アジリティ

そしてより具体の要素として以下３つの項目を強調している

1. ドメインによらない設計に関する考慮事項を明らかにするもの
2. 設計の構造的な側面に影響を与えるもの
   • 例えば、決済機能を持つシステムにおいて、セキュリティはアーキテクチャ特性として含まれるか？
     • 決済機能をサードパーティ性のものを使う場合は、セキュリティはアーキテクチャ特性にはならない
       • サードパーティの決済機能は利用者が最小限のセキュリティに配慮すれば使えるようになっているため
       • 決済機能を自前で実装する場合、あらゆる情報のやり取りに対するセキュリティ面の配慮が必要になりアーキテクチャ特性となる
3. アプリケーションの「成功」に不可欠なもの
   • 重要なアーキテクチャ特性は一握りであるはず。それを明らかにすること。
     • アーキテクチャ特性が多い -> あらゆる問題解決をしようする汎用性の高いシステムになる -> 扱いにくいシステムになる -> 成功しない
     • 扱いやすいという部分は重要で、それはイテレーティブになるように設計することの大事さ

3章 モジュール性

クラスや関数などの関連するコードのグループ化をモジュールと定義

本性ではこのモジュール性をどう計測していくかについて3つの要素の存在を提示している

1. 凝集度

• モジュール内の要素同士の関連度を示す指標
• 理想は関連する要素が１つにまとまっている状態
• LCOMメトリクスというものがある

1. 結合度

• 構造化プログラミング時代に出てきた概念

1. コナーセンス

• 結合度の概念をオブジェクト指向言語向けに再構築したもの

結合度とコナーセンスは内包されている要素は名前が違うだけで意味合いは重なっているものが多い

2章　アーキテクチャ思考

アーキテクチャ思考を語る上で重要な４つのこと

1. アーキテクチャと設計の違いを理解しチームがどう協働するかわかること
2. 他の人には見えないソリューションの可能性を見い出せる広範囲な技術知識を持つ
3. ソリューションと技術の間に必ずあるトレードオフを理解し、分析し、調整できる
4. ビジネスを伸ばすために乗り越えないといけない要素の重要性の理解とアーキテクチャへの反映

アーキテクトと開発者の違い

アーキテクトが求めること：技術の幅
開発者が求めること：技術の深さ

技術の幅と深さの関係は以下の図で表現できる

アーキテクトのコーディングへのコミット

アーキテクトは一定レベルの技術的深さは必要だが、それをどうやって獲得していくかの話

1. チームのボトルネックにならずにコーディングすることで実地経験を積める
2. クリティカルパスなどのコアな開発をやらずチームに移譲することで、チームのコアロジックへの理解とオーナシップが育まれる
3. アーキテクトが開発チームと一緒にビジネス関連のコーディングを行うことで、プロセスや開発環境に関するチーム課題を認識できる