bouzuya.hatenablog.com

ぼうずやのにっき

PAST #10 E, F, G, H を解いた / twiq 実装メモ

PAST #10 : 第10回 アルゴリズム実技検定 過去問 の E, F, G, H を解いた。

実装時に考えたことをメモしておくと良いかもしれない。毎日貼っているコミットの URL と合わせてみると良いかもしれない。そう思ったので試しに書いてみる。

bouzuya/rust-sandbox の twiq の実装メモはリポジトリにすこし残している。

https://github.com/bouzuya/rust-sandbox/tree/389a2b447463a061ec126bf7d9e4fd5d1022a8a0/twiq/docs

EventStore trait の簡素化

  • EventStore trait のメソッドをもうすこし簡素化したい
  • find_events と find_events_by_event_id_after の二種類がある
  • after: Option<EventId> を引数にして統一して良さそう
  • 時間的な余裕があるなら criteria にしておくほうが良さそう
  • 見えているユースケースが「ある EventId よりも後のもの」だけなので after: ... で進める

EventStream の追加

  • Vec<Event> となっているが EventStream にしたほうが良い箇所がありそう
  • EventStream は単一の EventStreamId を持ち、単調増加する EventStreamSeq を持つ
  • ↑の定義から一部は Vec<Event> で残すことになりそう (EventStreamId を横断する場合がある)
  • 「単一の EventStreamId を持つ」という部分を削る選択肢もあるだろうけど、現状は EventStream のグループごとに取り得る event type が分類されているので、 EventStreamId ごとに区切るほうが良さそう
  • EventStream は aggregate の実装の共通部分を削減する上で効果がありそう
  • EventStream への追加のために EventStreamSeq の増加など定形処理が多いので削れそう
  • 現在の目標から外れているので保留する

InMemoryEventStore の追加

  • InMemoryUserRepository で HashMap ではなく EventStore にして共有しないと他の repository を追加した際に困る
  • FirestoreEventStore を進めても良いがまだ一意性の検査などに時間がかかるので InMemoryEventStore を作って先に進めたい

User::from_event_stream の追加

  • InMemoryUserRepository で InMemoryEventStore から取得した Vec<Event> で User aggregate を再構築しようとして未実装なのに気づいた
  • User aggregate に手を入れるなら EventStream を実装しても良いかもしれない
  • 明日はここから

今日のコミット。