この、記事で言いたいことを先に言うならば、「ドメイン駆動開発したら、バグへるけど、理解してもらえる現場が少なすぎるよ」という嘆きである。
自分はいろいろな開発プロジェクトに参画してきた経験からいえることだが、開発コストがかかるのは、テストとバグ対応だと言える。
バグというのは、勘違いからくる。
たとえば、時間関連の勘違いも多い。
よく、深夜1時のことを25時として扱うというのがあったりする。これと、世界標準時間でいうところの時間とごっちゃにして、あれ、●月×日のデータがない。みたいなことを言ってたりとかする。
期間についても、開始と、終了を一つの期間という入れ物に持っておらず、 終了が、開始の前になっても、なんのチェックもしてないということにきづかないとかいう現場が結構ある。
これらは、小さなデータの単位をStringやDate形などで持つのではなく、責任を持ったデータを管理する入れもの(クラス)を用意することで防げるのだ。
それがValueObject?の使い方なのだ。
しかし、それを現場のリーダにレクチャーなどしようものならば、レクチャーされた側は、プライドを気づつけらたようなそぶりを見せる。間違いないとおもう。だいたいのリーダは、口では、「意見があれば、歓迎します」とかいうが、自分が見た感じでは、それぞれ価値観があり、それに反対する勢力としてカウントされてしまう傾向が強い。世渡り的には、アドバイスなどはしないのが良いということになってします。 中には、ValueObject?について、まちがった認識を逆にレクチャーしてきたケースもあった。
そういう時は、「あぁ、そうだったんですね。勉強になりました。」と答えるのが大人の返しかたなのである。
そういう現場は、謎のバグになやまされてかわいそうなことがおおいのだが、それは、リーダが自分のプライドを守ったつけを払っているのであるから、自業自得である。
そんな自分も最近Mysqlに格納したタイムスタンプと、格納したタイムスタンプを取得すると1秒ずれるという現象に見舞われた。
Mysql5.7以降は、データを取り込む再に値を四捨五入するようになったのだ。
ValueObject?でこの場合の時間の型のとらえ方を分けるのだ。なぜ、とらえ方を分けるのかというと、四捨五入が必要であるという知識と、実装を分離させるために分けるのだ。
例えばシステム時刻のことをRawDate?とかいう名称のクラスに格納するとして、データベースからselect文で取得した時刻のことをStoredDate?とかというクラスに分けて管理するのだ。
そして、RawDate?からStoredDate?に変換する場合は、MySQL5.7以降で行われる四捨五入の仕組みを入れるようにしておくのだ。
そうすれば、その四捨五入しなければならないという知識を、これらのクラスに閉じ込めておけるのだ。
クラスを利用する側は、そのMySQL5.7以降の知識を持たずに、安全にプログラムができるわけである。
プログラム量は増えるが、そこに使うコストがもったいない、とおもってはいけないのである、これは、バグを取り込まないようにするための必要経費なのだ。
疎通確認がおわり、単体テストがおわり、結合テストと、進めていくにしたがって、不具合を見つけるためのコストは増えていく、数行のコードを書く手間ぐらい、たいしたことはないのだ。
ところが、よのなかの、プロジェクトのリーダはそれがわかっていないのが、大多数だなぁと、いろいろなプロジェクトに参画してきておもうのであった。