「ドメイン駆動設計のためのオブジェクト指向プログラミングハンズオン」第2回に参加した結果、増田さんからPRにコメントをもらえた

f:id:blackawa:20171027181710p:plain

お忙しいところ、増田さんのご厚意に甘えて図々しくPRを見てもらえないかお願いしたら、ちゃんとコメントをもらえた。 勉強になった。

対象のプルリクは以下。

github.com

あらかじめ、書いていて疑問に思った箇所をこちらで注記してあって、それに対する返答という形でコメントをいただけた。

ドメインオブジェクトがことごとく toString() を実装することになる(がそれでいいのか...?)

良い。

自身を文字列表現するために、toString()を持つことが多い

たしかに、必要ないけどとりあえず用意したものは一つもなかった。 今まであんまり要らなかったのは、賢いオブジェクトを作り込むような設計ができていなかったからなのかな。

assertってアリなのか?

アリ。

メッセージは今回、

assert price.compareTo(BigDecimal.ZERO) >= 0 : "price is too small.";

みたいなものにしていたけど、本来はもう少し雄弁にした方が良いとのこと。少なくとも渡された値を表示はした方が良さそう。

計算結果ドメインオブジェクトを作って、そのコンストラクタに計算を任せる設計はアリなのか?

悩ましい。(が、ナシではないという意味だと解釈した)

今回のアプリケーションのクラス関係では、 Gross と GrossPerSubscriptionが、双方向に参照してしまっている。 GrossPerSubscription のコンストラクタには、Gross ではなく、Yen を渡すと解消できそうだとコメントいただいた。

ドメインオブジェクトのプロパティを文字列として返却する、ビュー用の関数が生える(のはアリか?)

一方、ドメインオブジェクトの設計が、(無意識に)ビューに引きずられがちになるという、ちょっといやな臭いを感じます。

たしかに!!!! 本当はもっとオブジェクト同士の関係を表す関数を生やしていきたかったが、うまいこと発想を膨らませられずビュー用のロジックばかり生やすことになってしまった。

DDD本、読む機運が今までになく高まっている。