Java読書会BOF 新しい課題図書「マイクロサービスパターン」を読む会を開始
本日8月29日より、Java読書会BOF主催の読書会「マイクロサービスパターン」を読む会が始まりました。
この本は、前回の課題図書投票で2位になっており、今回リベンジで課題図書となりました。
第1回
書籍のカバーのそでに記載される書籍紹介から読み始めました。電子書籍の人はカバーのそでがないという事態に。。。
第1章は、仮想のオンラインフードデリバリ会社FTGOの企業アプリケーションがモノリシック地獄の症状を示しているところから、マイクロサービスアーキテクチャへの切り替えに向かうための準備となります。
第1章の要旨
FTGOアプリケーションは、ヘキサゴナルアーキテクチャの下、外部のWebサービスを活用し論理的にモジュール化して作られ、1つのJava WARファイルにパッケージングしています。 ⇒ モノリシック
アプリケーションが小さい初期は、開発・変更・テスト・デプロイ・スケーリングしやすいと、さまざまな利点がありました。 成功を収め、次々新機能を実装するにつれコードが大きく複雑になり、コードベースと開発チームが大きくなるにつれ、複雑さに委縮、開発ペースの遅れ、デプロイに時間がかかる、スケーリングが難しい、信頼性が低い、陳腐化する技術スタック（フレームワークや言語）に縛られるといった、さまざまな問題が生じるようになりました。 ⇒ 泥だんご
そこでFTGOのCTOであるメアリーは、FTGOアプリケーションをマイクロサービスアーキテクチャに移行すると結論しました。
3軸のスケーリングの話、Y軸スケーリングではアプリケーションをサービスに分割、サービスを互いに疎結合でAPI以外では通信できない、手段の一つが個々のサービスに専用のデータベースを持たせる、といったマイクロサービス版のFTGOの概要を紹介。
続いて、マイクロサービスとSOAの比較、マイクロサービスの利点、欠点、そしてパターン言語とマイクロサービスアーキテクチャにおける各パターンのリストアップ（詳細は後続の章で解説）です。
章の最後にプロセスと組織に触れ、チームオブチームスでオーバーヘッドを抑えて開発、テスト、デプロイを素早く行う（DevOps）、といった内容です。
ヘキサゴナルアーキテクチャ
ヘキサゴナルアーキテクチャは、第1章で突如登場し、第2章で多用されています。書籍には由来は記載なかったようですが、調べると、Alistair Cockburn博士が提唱したアーキテクチャパターンの1つで別名をPort and Adapterというものでした。Cockburn博士の記事の日本語訳が次に掲載されています。
なぜ六角形なのか、は必要に応じてポートとアダプタを挿入するための余地としてとりあえず６としたようです。
アーキテクチャとして従来より多用されているレイヤーパターンの欠点を解消するものです。アダプターパターンや依存性反転（DI）パターンを組み合わせています。
第2章の要旨
ソフトウェアアーキテクチャの定義について、4+1ビューモデル、階層化スタイルとヘキサゴナルアーキテクチャスタイル、サービスとは何か、疎結合、共有ライブラリの疎結合への影響などについてざっと解説をした後、マイクロサービスアーキテクチャによるアプリケーションの作り方について述べています。
サービスの分割方法
2つのパターン
- Decompose by business capability
- Decompose by sub-domain
前者は、業務による分割で、まあ割とすんなり分かったような気になる分割です。後者はドメイン駆動設計（DDD）のサブドメインですが、この本だけでは分かりにくいです。
分割のガイドラインとして、ロバート・C・マーティン氏による次の原則を取り上げています。
- 単一責任の原則（Single Responsibility Principle）
- 閉鎖性共通の原則（Common Closure Principle）
第1回の感想
本書籍「マイクロサービスパターン」は、ソフトウェアの分析設計に関する本だった、というのが（今更ながら）読み始めてみて分かりました。
高水準ドメインモデルの作成では、アプリケーション要件（ユーザーストーリ・シナリオ）からモデルとしてのクラスと操作を抽出しますが、このあたりは「実践UML」に倣ったとあります。
サービスの抽出では、「ドメイン駆動開発（DDD）」を採用しています。
両方をある程度知っていることが望ましいので、できれば両方かじっておくとよいのですが、どちらの本も厚く難しい（特にDDD）ので躊躇してしまいます。
ということで、一人で読むのは厳しい書籍で読書会向きというところは間違いないです。
