前回(Level3)
Level3ではクラス分けすることを行いました。
しかし、私の目指すところのドメイン駆動開発になっていません。
また、ロジックもまだまだ複雑さが残っており、ぱっと見て何をやっているかがわかりにくいコードです。
これをドメイン駆動的な記述に直しました。
処理フロー
直すついでに、処理フローをより単純化し、分かり易くなるように修正しました。
・インスタンス生成
・商品リスト初期化(在庫補充)
・商品一覧表示(陳列商品の表示)
・商品選択(ユーザによる入力)
・入金(ユーザによる入力)
・販売(課金処理)
・おつり(返金処理)
動作イメージ
ソースコード
Qiitaに寄稿致しました。
Javaで作る自動販売機(ドメイン駆動)
なぜドメイン駆動か?
これは私の個人的な考えです。
仕様の明確化
サーバサイド(業務ロジック)のコーディングスキルは、
ドメイン(業務)に合うように記述すべきときが来ている。
コードを見て仕様がわからないし、
重複する箇所があれば修正は面倒この上ないことはすでに自明となっている。
保守性の向上
実際、前回の炎上プロジェクトでは同じロジックをコピペで3つの別々のクラスに書いた!
これは絶対に保守性を下げるし、
何らかの改修が入ったら仕様をしっている人以外は絶対にわからない!
受託元の独自FWの仕様と時間的制約から難しかったため断念したが、
共通クラスを作成して、メソッドに切り分けるべきだった。
仕様の齟齬を解消する
実装者がユーザに仕様をヒアリングできるのが当たり前になるべきだ。
仕様を確認した者が設計して、それを見て実装するのが当たり前だったが、
設計書の記述誤りや、設計漏れが出てくるのも当たり前である。
ヒアリングしたあとにすぐに実装して動いているものをユーザに見てもらえば、
設計は不要になる。(コードが仕様になるからだ!)
ユーザ満足度の向上
上記で述べた、実装とユーザ要求の齟齬が無くなることはユーザ満足度に直結する。
そして、実装者は誤った設計書を見て頭を悩ませなくなくて済むため、作業効率が上がる。
一石二鳥ではないか!