特定の値であることを保証するためにValueObjectを大量に作るのはどうなのか

PHPによるシステム開発の話です。

システムで予約ステータスを扱うとして
1．Contact
2．Confirmation
3．BeforePayment
4．AfterPayment
5．BeforeUse
6．Used

この予約ステータスが1～6であることを保証したり不正な変更を予防するために、予約ステータスクラス（ValueObject）として定義しておけば予約ステータス型かどうかを確認するだけで済みますし変更にも対応しやすいと思います。

こちらのサイトを参考にしました
https://qiita.com/Yorinton/items/f6138f2bca7664162ca3

Reservationクラス(Entity)のプロパティとしてこの予約ステータスクラスが使われているのですが、システムの規模が大きくなればこのようなValueObjectもたくさん必要になると思います。

こういう作りにしておけば堅牢なシステムになりますしいいなぁと思いつつも、ValueObjectクラスだけでも100個以上になりそうです。

実際のシステム開発において、必要なものは必要なだけ（極端な話1000個とか）クラスを作ったりするものなのでしょうか？それとも数が多すぎるからとセーブするものでしょうか？

1クラス1ファイルにするのでファイル数も多くなりますし、そんなにたくさんのクラスを定義してパフォーマンスやメモリは大丈夫だろうかなどと心配してしまいます。

実際に稼働している大きなシステムを見たことがなく、くだらない質問で申し訳ありませんが現場のお話などお聞かせいただければと思います。

追記

http://blog.shin1x1.com/entry/ddd-with-laravel
http://blog.shin1x1.com/entry/php-development-with-type-declration

こういうのを参考にすると必要な型クラスはいくらでも作るものなのかなと理解

実際にすべてのクラスが読み込まれる訳でもないですし、まずはパフォーマンスのことは考えずに構築してみて問題があってから考えた方がよさそう。。

「DDD パターンを活用した Laravel アプリケーション開発」スライド内で書かれている

VO内以外ではスカラー型は使わない（理想）

は衝撃でした。
もちろん（理想）となっているので状況に応じてだと思いますが、型をきっちり作ることでアプリケーション開発が気持ちよく進められるという意見に共感しました。

行動規範の内容に同意します

回答2件

ベストアンサー

PHPでのシステム開発はほとんど経験がないのですが、ValueObjectなどは普通に定義します。

逆のことを考えてみると良いでしょう。
全く同じシステムを運用するのに、ValueObjectが無かったとしたら、 status = 1 が Contact のことであるであると保証したり別のステータスの値と混同していないか常に気を配ったり、あるいは予約番号と金額を同じ数値で書いてしまって取り違いが発生しないかなどをチェックしたり…。
そういう自分たちが気にする文脈（AとBは意味の違う数字）などをクラスで表現しようとするとValueObjectになります。
ファイルが増えればそれだけ自分たちが気をつけるべき内容も大きく複雑なシステムなのですから、仕方ないことだと思います。逆に一つ一つのファイルが小さく分けられていることで、変更によるファイル競合が減ったり、長いコード行数に翻弄されなくなります。

もしカリカリにチューニングしてミリ秒単位の高速化を希望したり、少ないメモリの機器への組み込みの開発をするのであればメモリに関して気にする必要もあると思いますが、おそらく現在のサーバー環境では気にする必要はありませんし、場合によってはValueObjectの生存期間が短いことでGCなどに有利に働く可能性があります。

まずはValueObjectを作ってみて、自分たちの関心事などを言葉としてコードにしてみてください。きっと見通しが良くなると思います。
より詳しく知りたい場合はドメイン駆動設計なども参照すると良いでしょう。

投稿2018/05/24 12:56

編集2018/05/24 12:56