search

ModelingKai / meeting-room-python

1 stars 0 forks source link

「有効な予約」という型を導入するか #16

Open jnuank opened 4 years ago

jnuank commented 4 years ago

15 から派生した話。

is_available_reservation = lambda x: x.reservation_status == ReservationStatus.Reserved \
                                             and x.time_range_to_reserve.start_datetime > now

このあたりの処理なんですが、「有効な予約か？」という判定ロジックはドメインオブジェクトに寄せられそうな気がします！ 付随している「開始時刻が現在時刻より未来かどうか？」というロジックも寄せられそう(リファクタリングされたコードを見て初めて気づきました！ リファクタリングありがてえ！)。

なんでかっていうと、「有効な予約」というのは重要な概念だと思うからです。 現状の実装では、インフラ層のRepsoitoryの具体的な実装をみないと「有効な予約」の意味がわからないと思うんですよね。

気になるお題が3点

素直にドメインオブジェクトに実装しようとする前に、気になることは3つあってですね。 (ちょっと長いので、このPRはマージして、別途議論したほうが良いかも)

  1. Repository.find_available_reservations の時点で「有効な予約」という情報は十分に表現できているから、別にこのままで良い説 しかし、「有効」の意味を誤解して実装をミスっていたときに、現状のテストコードではそれを検知できない問題が生まれる(f511922 で消してもうた！)

  2. 現状の実装では、ドメインオブジェクト(Reservation)に、有効な予約かどうか判定ロジックを実装したとしても、利用するのはインメモリのRepsoitoryだけ(もし、インメモリのリポジトリ不要だと判断するなら、どこからも呼ばれない振る舞いになっちゃうけど、それってなんかへんじゃない？)。

  3. 現在時刻をどこで取得するか？ これは、現在時刻は "とりあえず" ドメインオブジェクト内で取得しちゃって良いと思ってます。重要ですが、別の話だと思うので。

mohira commented 4 years ago

ワシの考え。

決定事項: 有効な予約型 を導入する

具体的にどんな作業をすることで、有効な予約型がちゃんとできているって確かめるの？

テスト実装する。(昨日消しちゃったやつ！ )

あれ？ 既存の Reservation を直しながらやる？

そうすると、有効な予約型を作っているときに、既存のテストが壊れてしまう。 → 悲しい: 視覚的につらい。。。REDはこころにダメージがくる → 悲しい: うっかり、残しておくべきテストを破壊してしまうかもしれない

さらに、有効な予約型っていう話は、ドメインの重要な話なので、丁寧行くべき。というか不安。

以上より、

  1. まずは、有効な予約型だけでテストをする(このとき、既存のテストは変更しない)
  2. 有効な予約型のテストが出揃ったら、既存のReservationと見比べて、重複をなくす
    • Reservationのテスト内に、有効な予約型だけでやるべきテストが、たぶん、入っていると思っている
    • 重複があれば削除するし、移動するなら移動するだけ。
    • こうすれば、1つ1つのテストごとに戦える！

テストケースはどうするの？

〇〇

jnuank commented 4 years ago
  1. まずは、「有効な予約」型単体でのテストを実施する。
  2. その次に、TestReserveRoomUsecaseのテストからコピペして、「有効な予約」型に置き換えた、ユースケースのテストを実施する

という方針