中国DB勉強会のDDDハンズオンお題を2イテレーションやってみた

こないだのハンズオンのお題「有料無人駐車場」をDBじゃなくて、アプリケーションの方からやってみました。

mao-instantlife.hatenablog.com

1stイテレーション

まずは、駐車場でビジネスが成り立つ最小単位のモデリングをすることを目標とします。駐車上の前提は、単一の入庫用と出庫用ゲートを持つ駐車場で精算を出庫用ゲートで行う方式です。

シナリオ

1. 入出庫を管理したい
   1. 入庫したら管理開始
   2. 入庫したら連番が付与される
2. 入出庫情報から料金を計算する
   1. 単価×時間で計算

モデル

ご笑覧ください。

2ndイテレーション

次のイテレーションでは、入庫時に受け入れ可能かどうか判断するシナリオと、時間帯単価の概念を取り入れてみました。

追加シナリオ

1. 入出庫管理
   1. 入庫時に入庫可能かどうかの判断する
   2. 入庫可能なときは入庫し連番を付与する
2. 出庫時に料金を計算する
   1. 入庫情報から時間を算出する
   2. 入庫時間から時間帯単価を決定する
   3. 時間帯単価×時間で料金を計算する

モデル

ご笑覧ください。

モデルにもシナリオにも表現できていませんが「時間帯単価は重ならない」というルールがあるべきですね。また、入出庫の管理の中で料金計算があるべき、時間帯単価は入出庫ではなく駐車場に紐づくので、料金計算が駐車場に移動しています。

コード

ご笑覧ください。モデリング時にドメインロジックのことに頭が行かなかったため、テスト書くときに期待値に手間取ってしまってほとんど実装できていません。ぐずぐずです。

github.com

で、このドメインロジックに関するところですが、テスト書いてるうちに、シナリオの制約だとか永続化の制約とドメインの切り分けだとか、ルールだとかそういうモデルに反映しなければならないことがわかってきます。都度都度モデルに戻ってみたりする訳ですが、ドメインに対する最初のとっかかりの理解を得るまで、ドメインモデルのインターフェイスになる部分はまとまっても、ドメインロジックはあまり育たない、というのが実感です。これを後3〜4回繰り返していったら、理解が進んでもう少しましなコードになりそうです。

後は、Javaでやれば良かったなあ、と。6ヶ月のブランクですっかりScalaの基本的なところでつまづくようになっておりました。

反省点

• コード書く時間短すぎ(モデルの情報が反映しないままイテレーションが終った)
• シナリオ粗すぎ(テスト書かけるレベルじゃなかった)
• いきなりリポジトリとかファクトリとか考えるのやり過ぎじゃない？