この、記事で言いたいことを先に言うならば、「ドメイン駆動開発したら、バグへるけど、理解してもらえる現場が少なすぎるよ」という嘆きである。
* 言いたいこと、簡単に言うならば [#k9d15b45]
この、記事で言いたいことを先に言うならば、イソップ童話に例えると3匹の子豚の話にちかいかもしれない。「クラスを細かな分類でつくれば、バグがへって、後工程で楽なのに、理解してもらえる現場が少なすぎるよ」という嘆きである。

* 開発よりも、テストにコストがかかる [#e73bdfff]

自分はいろいろな開発プロジェクトに参画してきた経験からいえることだが、開発コストがかかるのは、テストとバグ対応だと言える。

バグというのは、勘違いからくる。

* よくある時間関連の間違いの例 [#s35e2121]
たとえば、時間関連の勘違いも多い。

よく、深夜1時のことを25時として扱うというのがあったりする。これと、世界標準時間でいうところの時間とごっちゃにして、あれ、●月×日のデータがない。みたいなことを言ってたりとかする。

期間についても、開始と、終了を一つの期間という入れ物に持っておらず、
終了が、開始の前になっても、なんのチェックもしてないということにきづかないとかいう現場が結構ある。

これらは、小さなデータの単位をStringやDate形などで持つのではなく、責任を持ったデータを管理する入れもの(クラス)を用意することで防げるのだ。

それがValueObjectの使い方なのだ。
それがValueObjectの使い方なのだ。イソップ童話の3匹の子豚の話で例えるならば、ValueObjectとは、レンガに相当するものだと思う。

* 現場リーダのプライドが導入の遅れ [#qa5ae571]
しかし、それを現場のリーダにレクチャーなどしようものならば、レクチャーされた側は、プライドを気づつけらたようなそぶりを見せる。間違いないとおもう。だいたいのリーダは、口では、「意見があれば、歓迎します」とかいうが、自分が見た感じでは、それぞれ価値観があり、それに反対する勢力としてカウントされてしまう傾向が強い。世渡り的には、アドバイスなどはしないのが良いということになってします。
中には、ValueObjectについて、まちがった認識を逆にレクチャーしてきたケースもあった。

そういう時は、「あぁ、そうだったんですね。勉強になりました。」と答えるのが大人の返しかたなのである。

そういう現場は、謎のバグになやまされてかわいそうなことがおおいのだが、それは、リーダが自分のプライドを守ったつけを払っているのであるから、自業自得である。

* 最近の自分の体験 [#y79e2344]
そんな自分も最近Mysqlに格納したタイムスタンプと、格納したタイムスタンプを取得すると1秒ずれるという現象に見舞われた。

Mysql5.7以降は、データを取り込む再に値を四捨五入するようになったのだ。

ValueObjectでこの場合の時間の型のとらえ方を分けるのだ。なぜ、とらえ方を分けるのかというと、四捨五入が必要であるという知識と、実装を分離させるために分けるのだ。

例えばシステム時刻のことをRawDateとかいう名称のクラスに格納するとして、データベースからselect文で取得した時刻のことをStoredDateとかというクラスに分けて管理するのだ。

そして、RawDateからStoredDateに変換する場合は、MySQL5.7以降で行われる四捨五入の仕組みを入れるようにしておくのだ。

そうすれば、その四捨五入しなければならないという知識を、これらのクラスに閉じ込めておけるのだ。

クラスを利用する側は、そのMySQL5.7以降の知識を持たずに、安全にプログラムができるわけである。

* 結局はレンガで家をたてばコストが安い [#sef0190e]
プログラム量は増えるが、そこに使うコストがもったいない、とおもってはいけないのである、これは、バグを取り込まないようにするための必要経費なのだ。

疎通確認がおわり、単体テストがおわり、結合テストと、進めていくにしたがって、不具合を見つけるためのコストは増えていく、数行のコードを書く手間ぐらい、たいしたことはないのだ。

* まだ、わかってない人が多い [#g03f2326]
ところが、よのなかの、プロジェクトのリーダはそれがわかっていないのが、大多数だなぁと、いろいろなプロジェクトに参画してきておもうのであった。


トップ   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS