[戻る]

Java読書会BOF 「マイクロサービスパターン」を読む会 第1回

開催概要
日時 2021年8月29日 10:00 - 17:00
場所 てくのかわさき 第４研修室
出席者(敬称略) 高橋(智)、高橋(徹)、根本、岩永、松永、加藤、吉本、遠藤、平山、岩室(書記)

表紙折り返し

はじめに

謝辞

監訳者前書き

本書について

本書はどのような人々のために書かれているか

ロードマップ

コードについて

ブックフォーラム

その他のオンラインリリース

著者について

監修者について

訳者について

Chapter1 モノリシック地獄からの脱出

1.1 ゆっくりとした足取りによるモノリシック地獄への転落

  • Big ball of mud (大きな泥だんご) パターン → データ指向アプリケーションデザイン(前回の書籍)の第1回参照

1.1.1 FTGOアプリケーションのアーキテクチャ

  • FTGOのモデルはUberEats?
  • ヘキサゴナルアーキテクチャ?

1.1.2 モノリシックアーキテクチャの利点

1.1.3 モノリシック地獄の実際

  • 機能ブランチが機能しない件
    • 同じコードベースをさわっているのでマージが大変
      • 「マージが大変」という事態はあるか?
        • svnのときは大変だった
        • gitの場合はあまりないように思う。プルリクエスト/マージリクエストがあるので割と大丈夫
        • 「同じコードベース」というのが問題なのでは。頻繁にコンフリクトが発生する可能性がある

1.2 本書がみなさんにとって意味を持つ理由

1.3 本書で学べること

1.4 マイクロサービスアーキテクチャで状況打開

  • イリティ(-ility): 「-イリティ(-ility)」がサフィックスに付く語(例えば「メンテナンシビリティ(maintainability)」)の集合を指す。
    • IPAの「非機能要件グレード」にも相当する考え方はあるが十分ではなく、実際の「-イリティ」は膨大であり、対象によって何を重視するかを検討する必要がある。
      • IPAの「非機能要件グレード」をダウンロードして「グレード表」を眺めてみたが、小項目レベルだとかなりの数があったので、これでも不十分なのかとちょっと目が遠くなる。

1.4.1 スケールキューブとマイクロサービス

  • 参加者の経験した事例として、APIのリクエストが1画面210あるようなケースがあった。
    • 分けてはいけない要素を分けたせいなのでは。
      • 本書の後の方に出てきそう。

1.4.2 マイクロサービスはモジュール性の一形態

  • そこでモノリシックでも(Java9以降の)Javaモジュールを採用すればw

1.4.3 個々のサービスは専用のデータベースを持つ

1.4.4 マイクロサービスアーキテクチャのFTGOアプリケーション

  • WebUIの場合はAPIゲートウェイを使わないのか? (=何故各サービスのREST APIを直接叩いているのか?)
    • 後で言及されるとのこと (数ヶ月後?)

1.4.5 マイクロサービスアーキテクチャとSOAの比較

  • SOAの比較は少々こじつけっぽい。
    • SOA(というかSOAP?)は、規格自体はきっちりしているかもしれないが、過去の事例として、実装が微妙なケース(WSDLが無い、XMLの規格に正しく従っていない、など)もしばしばあった。

1.5 マイクロサービスアーキテクチャの利点と欠点

1.5.1 マイクロサービスアーキテクチャの利点

  • 図1.8: サービスやサービスのリポジトリは独立しているが、サービス間で連携するとき、API情報の提供や取得はどうするのか?

  • 図1.6にある顧客サービスが図1.8にない。(例示だから?)

  • UberEatsの場合、店と客が直接情報を共有していない。(店には客が誰だかわからない)

  • サービスをまたいでどこでも使うサービスはどのように扱うのか?

  • 個々のサービスのテストは容易になるかもしれないが、サービス全体のテストはどのように行えばよいのか?
    • APIが変わらなければ大丈夫なはず?
    • データを共有しておらず、APIだけが公開されているから、そこまで大きな影響はないのでは?

  • いろいろ出ている不明点は後から出てきそう。

1.5.2 マイクロサービスアーキテクチャの欠点

  • 「デリバリースキルが高くなければなりません」
    • デリバリースキル持ってる人、ほとんど見たことないよ!?

  • k8sなど: インフラ屋さんが追随できないことが多い。

  • k8sなどのツールに依存するのは違和感がある。

1.6 マイクロサービスアーキテクチャのパターン言語

1.6.1 マイクロサービスアーキテクチャは万能薬ではない

1.6.2 パターンとパターン言語

1.6.3 マイクロサービスアーキテクチャのパターン言語の概要

1.7 マイクロサービスを越えて: プロセスと組織

1.7.1 ソフトウェア開発とデリバリー組織

  • ベロシティ ≒ 開発速度?

  • 「Apache Verocity」というテンプレートエンジンがありました。
    • 7年たって2.0が出たらしい。

1.7.2 ソフトウェア開発とデリバリープロセス

1.7.3 マイクロサービスを受け入れる人々について考慮すべきこと

1.8 まとめ

  • まず、組織をマイクロサービスに適応できる構成にする必要があるようにも読める。

Chapter2 サービスへの分割

2.1 マイクロサービスアーキテクチャとは正確なところ何なのか

2.1.1 ソフトウェアアーキテクチャとは何か、なぜ大切なのか

2.1.2 アーキテクチャスタイルの概要

2.1.3 マイクロサービスアーキテクチャはアーキテクチャスタイルのひとつ

  • ポートとアダプタ
    • ポート ≒ インターフェース
    • アダプタ ≒ 実装
    • DAOの場合、(Java)インターフェースはビジネスロジック側が持つ
  • ヘキサゴナルアーキテクチャ - 何故六角形? (宿題)
    • 外界とポートで繋ぐ考え方
    • クリーンアーキテクチャとの関係は?

  • 丸で表した場合 → オニオンアーキテクチャ?

2.2 マイクロサービスアーキテクチャの定義の方法

2.2.1 システム操作の洗い出し

  • ConsumerにAddressが紐付いていない?
    • DeriveryInfoにAddressがコンポジションになっているので、ここにあるのでは?
    • 全部の線をひっぱると線だらけになるので省略されているのでは?
  • 時間経過的のものが記述されていない(注文後に住所変更した場合とか)?
    • サンプルだから、そこまで細かい情報が記載されていないのでは。

2.2.2 〈Decompose by business capability〉パターンによるサービスの定義

2.2.3 〈Decompose by sub-domain〉パターンによるサービスの定義

  • 業務に基くサービスの定義は、図2.8を見ても思考の流れが比較的わかりやすいが、サブドメイン(≒DDD)に基くサービスの定義は、図2.9を見ても思考の流ればわからない。
    • 「境界づけられたコンテキスト」を学ぶ必要がある?
    • DOAに近い? オブジェクト指向分析の系譜?
    • MDA(モデル駆動アーキテクチャ)?

2.2.4 分割のガイドライン

次回は 2.2.5 (p.62) から。

(以上)

[戻る]