validationをどこで実行するか

リクエストでpostされたデータ(大体Json)をどこでバリデーションするのが良いか

DDDではDomainに業務ルールを集めるため、値が不正かどうかを判断するのはDomainである。したがってDomainへ変換する際にバリデーションすべきであると考える。または、クリーンアーキテクチャではデータを受け取るControllerは一番外側に位置するため、第2候補としてそもそもこの円の中に入れる前にバリデーションするのも手である。ただし業務ルールはDomainをが持つ物であるため当然バリデーションルールはDomainが持つべき情報である(2回目)。したがってDomainへの変換時点でのバリデーションはmust、手前で弾くのは究極どちらでも良いがやれるならやった方が良い程度のものじゃないかと最近思ってきた。そもそもデータを連携してくるシステムや連携経路(どのAPIを通してDomainまでくるか)は多用であるため、Domainへの変換時点以外でのバリデーションを頑張ると処理が各経路ごとに分散してしまい効率が悪い。やっぱりDomainでバリデーションを(以下略3回目)

Controllerでのバリデーションは不要?

いや、必要。Domainはビジネスルールのバリデーションを実施し、Controllerは表層的なルール?例えば必須項目や文字数とかを実施すべきな気がする。まとめると結局外部からデータをControllerで受け取る際表層的なルールのバリデーションを実施、Domainへ変換する際ビジネスルールでバリデーションすべき。

データの受け渡し

データは何かしらの処理が施され、最終的にドメインへを作りたい(変換したい)。変換方法はコントローラーが受け取ったデータをそのままドメインへ変換するか、一度DTO(form objectみたな)を経由してドメインへ変換するかの2択。上記バリデーションすべき箇所がコントローラーとドメイン両方で実施するなら一度fromオブジェクトを経由した方がよさそうな気がする。

json→domain or json→form object→domain

いろいろ整理してみたが、結局のところリクエストデータを一度formオブジェクトで受けるかどうかは宗教上の問題と聞いた。個人的にはfromで一度受けた後Domainで変換した方が、バリデーションの責務がハッキリするため良いと感じている。また、一度fromで受けるのであれば、from→domainへの変換テストを各form事に書けば良いのでjson→domainよりもテストが楽である。formを介してデータを受けない場合、表層的なルール及びビジネスルール両方を考慮したクソデカJsonを毎度用意する必要があるためテストの見通しが悪い。また、データの組み合わせテストが発生するため、テスト量も増えてしまう。