O’REILLY Learning「マイクロサービスアーキテクチャ 第2版」13〜16
content/uploads/2023/02/9784814400010.jpeg" alt="" width="400″ height="568″ class="alignnone size-full wp-image-6851″ />
https://learning.oreilly.com/library/view/maikurosabisuakitekutiya-di-2ban/9784814400010/
13章 スケーリング
Martin L. Abbott、Michael T. Fisher「The Art of Scalability」
・垂直スケーリング（vertical scaling）
・水平複製（horizontal duplication）
・データのパーティション分割（data partitioning）
・機能分解（functional decomposition）
キャッシュ
・パフォーマンスのためのキャッシュ
・スケールのためのキャッシュ
・堅牢性のためのキャッシュ
14章 UI
「フルスタックチーム」
顧客指向の主要業績評価指標（KPI：Key Performance Indicator）
パターン：モノリシックフロントエンド
パターン：マイクロフロントエンド
パターン：ページベースの分解
パターン：ウィジェットベースの分解
パターン：中央集約ゲートウェイ
パターン：BFF（フロントエンド向けのバックエンド）
BFF（フロントエンド向けのバックエンド、Backend for Frontend）
15章 組織構造
Jez Humble、Gene Kim「Accelerate」
最適なパフォーマンスを実現するために、どの行動が最も重要かを深く理解するため、自律的で疎結合のチームの特性
・チーム外の誰かの許可なしに、自分のシステムの設計を大規模に変更できる。
・他のチームがシステムを変更したり、他のチームのために大幅な作業をしたりしなくても、自分のシステムの設計を大規模に変更できる。
・チーム外の人とのコミュニケーション、調整をしなくても、自分の作業を完了できる。
・依存している他のサービスにかかわらず、要求に応じて、製品、サービスをデプロイ、リリースできる。
・統合テスト環境がなくても、要求に応じて、大部分のテストを実施できる。
・通常の業務時間中に、無視できるほどの停止時間で、デプロイを実施できる。
コンウェイの法則
（情報システムだけではなく、より広い意味で定義された）システムを設計するあらゆる組織は、その構造がその組織のコミュニケーション構造の複製となるような設計を、必然的に生み出す。
コンウェイの法則は、疎結合の組織が疎結合アーキテクチャをもらたす（その逆も同様である）ことを示している。
イネイブリングチームは、複数のストリームアラインドチームを横断的にサポートするように働く、と想定。
16章 進化的アーキテクト
アーキテクトには、自分が作成した環境が、その環境の中で作業するのが快適なようにする責任がある。
Patterns of Softwareの著者Richard Gabriel
居住性は、ソースコードの特性だ。
これにより、後からコードに関わるプログラマが、コードの構造、意図を理解し、快適に自信を持ってコードを変更できるようになる。
規則は、愚者が従うべきものであり、賢者の手引きとなるものである。
HerokuのTwelve Factors：https://www.12factor.net
Herokuプラットフォーム上で適切に機能するアプリケーションの作成を助ける、という目標のためにまとめられた設計原則集。
12ファクターアプリは、SaaS型アプリを構築するための方法論です。
最近この手の本が多いが、間違ってはいけないのは、マイクロサービスが万能なわけではないということだ。
そこを理解し、学習し、得た知識を使っていくことが大切。