[戻る]

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

開催概要
日時 2021年12月18日 10:00 - 17:00
場所 てくのかわさき 第4研修室
出席者(敬称略) 松永、高橋(徹)、遠藤、加藤、平山、岩室、今井(記)

本日は、p.229 の 6.2 からです。

Chapter 6 イベントソーシングを使ったビジネスロジックの開発

6.2 イベントストアの実装方法

  • p.229 中程 Lagomの項: Typesafeは(Lagomではなく)Lightbendの以前の名前。

6.2.1 Eventuate Local イベントストアの仕組み

  • p.231: PKにvarchar(1000)ってあまり使わないよね。
    • varcharは可変長で記憶域は入れた値程度しか使用されないので(1000)はあまり気にならない。
    • btreeのキーには（ハッシュではなく）PKの値そのままはいっていたはず。

6.2.2 Eventuate Client フレームワーク

  • p.234 図6.10など: クラス名などの、図、リスト、本文での違いが散見される。
    • CreateOrder(図6.10) : CreateOrderCommand(p.235 リスト、本文)
      • githubにあるソースコードではCreateOrderCommandは検索しても無かった。
    • createOrder()(図6.10) : create()(p.236 本文)
  • p.234 図6.10: 右下OrderServiceEventHandlersにある、creditReservedとはどういう意味だろう?

6.3 サーガとイベントソーシングの併用

6.3.1 イベントソーシングを使ったコレオグラフィベースのサーガ実装

  • p.239 l.14: 脱字

    ビジネスルール反する -> ビジネスルールに反する

6.3.2 オーケストレーションベースのサーガ実装

  • p.240 リスト @Transactionalの下の行のインデントがおかしい。

6.3.3 イベントソーシングベースのサーガ参加サービスの実装

  • p.244 図6.12

    • イベントストアの .... はイベントが並んでいるイメージ。

    • 衍字

      Authorize Accouunt -> Authorize Account

    • リスト6.6と表記の違い

      Authorize Account コマンドハンドラ(図6.12) : AccountingServiceComamndHandler(リスト6.6)

    • Eventuate APIからイベントストアに伸びている矢印の根元は、アグリゲートリポジトリではないか。

6.3.4 イベントソーシングを使うサーガオーケストレータの実装

6.4 まとめ

  • やはり全体通して一つのアプリケーションとして見るのが難しいですね。
    • JavaScriptの非同期処理Promise, Async/Awaitの様にもう少し何とかならないのかなぁ。
  • 全体を通して同じミドルウェアが必要なのだろうか。
    • イベントストアなどAPIが同じであれば実装は別でも（別のミドルウェアでも）良い。
  • ログが分散されてしまって追いかけるのが難しそう。
    • ログにイベントIDを付けておく。
    • AndroidのログにはスレッドIDがついている。

Chapter 7 マイクロサービスアーキテクチャでのクエリーの実装

7.1 〈API composition〉パターンを使ったクエリー

7.1.1 findOrder()クエリー操作

  • p.253 図7.1: オーダーステータスビューの情報項目と各サービスの属性名は日本語/英語を合わせてほしかった。
  • p.254 図7.2: queryA()のロリポップの線が短い。プロバイダサービスAに接続される。

7.1.2 〈API composition〉パターンの概要

7.1.3 〈API composition〉パターンを使ったfindOrder()クエリー操作の実装

7.1.4 〈API composition〉パターンの設計上の問題点

  • p.257:図7.5とp.258:図7.6の違いは、
    • 図7.5: APIコンポーザはAPIゲートウェイにある複数のAPIの内の一つfindOrder()に実装する。
    • 図7.6: APIコンポーザは専用のFind Order ServiceのfindOrder()に実装する。

7.1.5 〈API composition〉パターンの利点と欠点

  • p.260: 大規模なデータセットをメモリ内で結合しなければ...に関して。
    • IDで検索でなく複数サービスに分散した属性をキーに検索する場合などが考えられる。
    • 以前、種類が異なるセンサーのデータを同一タイムラインで表示したいとき、各センサーからどっさりデータを持ってきて処理したことがある。

7.2 〈CQRS〉パターンを使ったクエリー

7.2.1 CQRSを書く理由

  • p.263: 地理空間拡張とは?
    • 緯度経度をデータとしていれておき指定領域上にあるレコードを検索する、などができる拡張機能。

7.2.2 CQRSの概要

  • p.265 図7.8: CQRSの左側にはRはいらないのか。
    • RはRESTではGETのようなもので、他のPOST, PUT, DELETEもデータを返せるので、Rはいらない。
  • p.266 下方: 「業務分担上のニーズからそのチームの担当とすべきでない仕事があるとき」とは何を言っているのだろうか。

7.2.3 CQRSの利点

  • p.723: 「関心事」の読みは（「かんしんごと」ではなく）「かんしんじ」。

7.2.4 CQRSの欠点

7.3 CQRSビューの設計

7.3.1 ビューデータベースの選択

7.3.2 データアクセスモジュールの設計

  • p.274: キーに≪aggregateType≫だけでなく≪aggregateId≫も必要なのはなぜ? - 後節で詳しく説明されることに期待。

7.3.3 CQRSビューへの追加と更新

7.4 AWS DynamoDBによるCQRSビューの実装

  • p.275: AWS DynamoDBは正式にはAmazon DynamoDB。

7.4.1 OrderHistoryEventHandlersモジュール

  • CQRSは...
    • マイクロサービスに特化したものではなくモノリシックからあった。
    • マイクロサービスに相性が良いので説明されている。
  • p.276: 下方の「APIモジュール」、「DynamoDBテーブル」のフォントに違和感がある。
  • 表記不統一
    • OrderHistoryDAO(図7.12) : OrderHistoryDao(リスト7.1)

7.4.2 DynamoDBにおけるデータのモデリングとクエリーの設計

  • p.280: グローバルセカンダリインデックスはマテリアルビューのようなものか。

Note

次回は、p.280 findOrderHistoryクエリの実装 から。

[戻る]