こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
会の概要
今日は割り勘モデリングを再度やっていきました。
今回はイテレーションを重ねていく中でモデルを洗練させていく方針を取ろうという話になりました。
会の様子
前提条件を決める
以下の前提条件を決めていきました。
- 参加者の名前はシステム利用時に毎回必ず名前を登録する(DBのようなところに登録されているわけではない)
- 幹事が全額払ったあとに割り勘をする
- 分け方は大, 中, 小の3段階のみとする。(1000円, 2000円, 3000円, 4000円, 5000円といった分け方はできない)
イテレーション1
まず、一番シンプルな方法でモデリングをしてみようということになり、割り勘の仕方としては、金額 / 参加人数のみの方法で実装してみようという話になりました。
モデルとしては以下2つが考えられるという話になりました。
そのうえで、どちらがいいかという議論をし、飲み会が参加者人数を計算するロジックを持つのは、将来的に飲み会クラスが肥大化していくようなリスクを抱えているため、参加者集合という概念を挟み、そのクラスが参加者の人数を計算する方法がいいのではないか？となりました。(例えば赤ちゃんは参加人数にカウントしないといったロジックを追加する時は参加者集合がロジックを計算するようにする)
イテレーション2
イテレーション2では、参加者ごとに2種類の支払い区分を設定するという方針でやっていきました。
そのうえで、まずはイテレーション1のモデルで変更したい部分を洗い出し、
- 金額を計算するのは飲み会から切り離したい
- 支払い区分という概念を追加したい
という話が出ました。
そのうえで、参加者が支払い区分を持つほうがいいのか、支払い区分が参加者を持つほうが良いのか？という議論をしていきました。
参加者が支払い区分を持つ方法を取る場合、
- 支払い区分が複雑な概念になると変更に弱い
- 幹事が知りたいのは参加者の詳細というよりも支払い区分ごとに何人いるのか？という情報だけなので直感的ではない
というデメリットがあるという話になりました。一方で、支払い区分が参加者を持つ方法を取る場合、
- 参加者が複雑な概念になると変更に弱い
- 支払い区分ごとの計算方法が実装されると(端数は支払い区分大の人が払うなど)支払い区分クラスを個別に実装する必要が出てくるため、変更が大変なことになる
というデメリットがありそうだという話になりました。
全体を通した感想
途中抜けでしたが、イテレーションを重ねながらモデリングを洗練させていく方針のほうが、前回のモデリングよりも考えることが分割されてやりやすいなあというのは改めて感じました。
次回は実装の部分にまで踏み込んでやってみたいです！
