[戻る]

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

開催概要
日時 2022年2月19日 10:00 - 17:00
場所 川崎市教育文化会館 第3会議室
出席者(敬称略) 高橋(徹)、遠藤、平山、岩室、吉本、加藤

第8章 外部 API パターン

8.3 API ゲートウェイの実装

8.3.3 GraphQL を使った API ゲートウェイの実装

注釈

本日は、p.321 の GraphQL スキーマの定義から

  • p.323 一意に識別された ID 型とあるが、これは事前定義されたもの？
    • 一意であることを GraphQL 側が保証する文字列型みたい
  • p.326 文中で1箇所だけ Promise がカタカナで「プロミス」と書かれているのは誤植だろうか
  • p.329 リスト8.10 の 1 はヒアドキュメント的なものだろうか
    • ES6 のタグ付きテンプレートリテラルのようだ (gql がタグにあたる)
    • IDE がテンプレート内までシンタックスハイライトしてくれるのかも

8.4 まとめ

  • GraphQL の定義を書くのは Swagger で YAML ゴリゴリ書くよりは良い開発体験に思える
    • コードから YAML を自動生成させる手段もあるけれども

第9章 マイクロサービスのテスト (前編)

  • ロジックがデータベースに寄っている場合に自動テストがしんどい
    • SQL の動作は事前条件・事後条件が明確で自動テストしやすい部類ではないか？
    • データベース上にある状態の遷移がいろいろなところと複雑に絡み合っていると様々なパターンが必要で簡単ではない
    • テスト用のデータをどかっと用意して流すでも良いが、テストデータのメンテナンスコストもかかるよね
    • 最初からテスタビリティを重視して設計していれば・・・
  • "モノリシック地獄" というが、責務の分担など正しく設計できるかどうかの問題であって、モノリシックかマイクロサービスか以前の問題ではないか？
    • マイクロサービスだって依存関係があるわけで、マイクロサービスにしたからって解決にはならないよね
    • それにマイクロサービスになったとしても UI (フロントエンド) は結局モノリシック
  • 一つのデータベースを複数のプロセスが書き込む設計はろくなことにならない
  • (いろいろと盛り上がったがひとまずこの章を読むモチベーションは高まった！)

9.1 マイクロサービスアーキテクチャのテスト戦略

9.1.1 テストの概要

  • p.341 図 9.4 ではコンポーネントテストが第1象限にあるが、ページ下部の箇条書きでは第2 象限に分類されている
    • コンポーネントテストの定義は、 p.340 によると「個々のサービスの受け入れテスト」、このサービスってマイクロサービス？
    • サービスにとってのユーザー、別のサービスにとっての受け入れテスト？
    • 図 9.4 は本の著者によるものではないので矛盾があっても仕方がないかもしれない
    • でも引用元の図には4象限の分類の説明のみで、その中までは書いていない
  • そもそもこのテストの概念・枠組みっていつ生まれたものなのか？
    • JUnit とか TDD とかが生まれた時代か (Kent Beck が始祖か)
    • スタブ・ドライバーを使って SUT をテストするという概念はもっと古くからある
  • 機能テストはビジネス面で、非機能受け入れテストは技術面なのはどう捉えれば良いだろうか、どちらもユーザー要件になりうるが
    • パフォーマンステストは技術面にはなっている
    • 要件次第 (ドメインエキスパートの用語になるかどうか) で、きれいに線引きできないところだと思う
  • p.342 図 9.5 は、引用元の Martin Fowler のサイトでは上から順に UI Tests, Service Tests, Unit Tests になっていて、本文とは異なっている
    • 横幅はなにか意味があるのだろうか？
      • そもそもピラミッドにしている意味はあるのだろうか？四角形を積み上げるではなく
      • テストの数だとすればしっくりくる

9.1.2 マイクロサービスをテストすることの難しさ

  • p.344 図 9.6 の矢印はデータの流れ？依存関係？
    • 依存関係を示していて、データの流れは E 以外はどちらもありうる
    • E は event、C は command の略だろうか
  • コンシューマー駆動契約テスト、斬新かも
    • 呼び出し側にテストコード書いてねって依頼するのはハードル高いと思った
    • サービスの呼び出し側のみ持っているデータで試したいときは、呼び出し側にテストを依頼しないといけないので、枠組み自体は珍しくない
    • プラクティスとして積極的に実践するのは確かに斬新かもしれない
  • p.347 中盤 "Groovy という DSL (ドメイン固有言語) を使っています" とあるが、Groovy 自体は DSL ではないので記載誤りと思われる
    • 翻訳ミスの可能性もありうる
  • p.348 図 9.8 はどっちのチームにもメリットがある合理的な仕組み、よくできているなと感じる

9.2 サービスのユニットテストの開発

  • p.352 社交的なユニットテストは本番環境を叩くのだろうか？
    • さすがにテスト環境のものではないだろうか
    • テストケースが多ければ短時間に大量のリクエストが飛んでしまう

注釈

本日は、 p.353 の一番下まで

[戻る]