全体
一言でいうと名著ですね。ここ2～3年、洋書を読むをさぼっていて翻訳がでるまで読まないでいたところが反省点です・・・
DevOps逆転だ依頼のインパクトです。他にいい本はあるのですが、インパクトという意味では久々な本です。
そのうえで、MSA（マイクロサービスアーキテクチャ）は概念であり、それぞれの技術がMSAを実現可能にあるいはMSAのために開発されてきているといえるのではないかと思いました。
（特に2章はアーキテクトのあり方、アーキテクチャが実現する原則、目標、標準、プラクティスなどが語られており、その概念を強く感じました）
- 残念なところ 各項目の関係性や粒度が章・節でばらばらに見えてしまうので体系として読みにくいです。ただ、それは逆に整理しながら読めばいいだけなので名著であることは変わりません。逆にいうと、各章、各節単位で興味があるところから読むということも可能だと思います。
考えるべきこと(後で加筆予定）
- 疎結合で凝集度の高い面で全体を切ることができるか
- 組織が変わる場合にその境界が分かれることが望ましい
- 非機能要件（機能横断要件）が異なる場合。（NoSQLとDBMSなど）
内容
MSAが必要となる理由
1.2 主な利点に書かれています。
* 技術異質性
* 回復性
* スケーリング
* デプロイの容易性
* 組織面の一致
* 合成可能性
* 交換可能にするための最適化
スケーリング、デプロイの容易性等はそうだろうなと思っていたのですが、まだまだ利点がありました。
境界づけられたコンテキストの重要性
3.3に記載がありますが、サービスをどう定義すべきかを考える上で重要に思います。
3.3.1共有モデルと隠れモデル、3.5ずっと下の亀は関係があって、共有モデルをさらに詳細化して、分割して接合部を明確にすると隠れモデルが明確化される関係があるのではと思いました。
このような内容に基づいて、どう接合部を見出すことができるかが鍵だと考えます。
境界づけられたコンテキストがマイクロサービスになり、接合面がインタフェースになるのかなと考えながら読みました。
処理方式
前半の山場がここかと思ってます。このあたりをきちんと考えることができればアーキテクチャとしてはしっかりするのではと思ってます。（非機能要件（機能横断要件）次第ではもっと考える必要がありますが、それは別の書籍に詳細が書かれています）
同期と非同期 (4.4)
処理方式の基本的な概念が最初に書かれています。
オーケストレーションとコレオグラフィ（4.5）
最初にリクエストを受け取ったサービスがファサードのように動作し、他のサービスと協調するのがオーケストレーション。
最初にリクエストを受け取ったサービスが自分の処理をおこない、その処理をおこなったイベントを発生させ、そのイベントを受け取って処理する各種サービスが自分のそのイベントに対する対応をおこなうことで処理をおこなうのがコレオグラフィ。
同期と非同期、オーケストレーションとコレオグラフィを組み合わせるといろいろな処理パターンが生まれます。
コレオグラフィってキューを使ったSub/Pubモデルでしか意識していなかったんですが、非同期という軸を外して考えると同期でも確かにできそうですね。待ち合わせや結果の取得を考える必要がありますが。（同期にするメリットはどこだという話もあります）
技術選択
- RPC (4.6)
- REST (4.7)
- 非同期イベントベース連携の実装 (4.8) 同期技術としてRPC（リモートプロシジャーコール）、RESTを紹介している。このあたりがこの本のすごいところで、これらのテーマを短いページ数で最新の情報に触れようとしている。（さすがThoughtWorksの人です）
注意点
MSAを構成する技術要素として、いくつかのポイントを挙げています。
特に4.13 バージョニング、4.15.5 ストレングラー（絞め殺し）パターンは昔に考えたことがあったので、なるほどと思いました。
現状の単一システムをどうサービス化するか（5章）
単一の大きなシステムをどう分割するかという点を記載しています。
分割理由
分割理由が明確に書かれているのが素晴らしい。5.3.1 変化の速度がすべての理由かと思ってましたが、チーム編成、セキュリティ、技術もその理由になるのかと思いました。
データベースの分割（5.5～）
各種サービスに分割して、同じDBMSを見ていた場合、目的を達成できるかわかりません。（コードベースを小さくするという意味ではいいのでしょうが）
そのためにもデータベースの分割は大きなテーマです。
そこについても明確に記載されています。
情報系システムへの対応 (5.14～)
いわゆる情報系システムへの対応について、5.16データポンプという概念のソリューションを交えて記載されています。データポンプはETLのETにあたる部分をサービスでもち、サービスの境界内の大きなデータ連携に対してET機能によって、データを提供するというサービスを実現するものです。
情報系システムのデータの鮮度からするとこのやり方で十分で、同期である必要ないので【バッチ】的な考え方でもいいかもしれません。
データだけではなく、イベントをまとめて処理して情報系DBを作るソリューションも記載されていました。（5.17 イベントデータポンプ）
デプロイ
デプロイはアプリケーションが先に書かれていましたが、私としてはインフラ（環境）から考えた方が考えやすいので、以下はそう記載しました。
インフラ
6.4 プラットフォーム固有の成果物から始まり、サービスをどのように配置するか、MSAが要求するスピードでその環境を準備できるかという内容が記載されています。（6.4～6.9、6.11～6.12）
特に、6.9 サービスからホストへのマッピングはパターンをかなり細かく考察しており、再認識しました。
アプリケーション
CI、リリースをおこなうためのパイプライン、サービス単位のコードベースをどう管理するべきかということが記載されています。
このあたりはMSAでなくても考えなければならないところです。サービス単位のコードベースをどう管理するかは、MSA固有ですが。