⇧ 自然の中にいたとしても、やることが変わらなければ、時間はゆっくり流れているように感じない気はしますな。
未曾有の情報化社会となった現代において、タスクが山積みになっているのが普通ですからな。
まぁ、どっちにしろ、「時間がゆっくり流れているように感じる」としても物理的に「時間の流れは変わらない」わけなのだけど、精神的な心の平穏が得られるということですかな。
何となく、
⇧ 上記のような階級に属する人間は、ストレスフリーな日々を過ごしている気はしますな。
JavaでController LayerではなくService LayerでDTOのバリデーションするには
JavaでSpring FrameworkのSpring Web MVCを利用することが多いので他のフレームワークにおけるMVCモデルでの挙動が分からないので、何とも言えないのだけど、Spring Web MVCだと、Controllerクラスで用意されているメソッドにアクセスがあった時にバリデーションされる例が多いように思う。
つまり、外部からリクエストされてきた値を自動でバリデーションしてくれる感じ。
勿論、リクエストされてくる値にマッピングできるJavaのクラスのオブジェクト、一般的にDTO（Data Transfer Object）と呼ばれるものを用意しておく必要があると。
ただ、Java側でService LayerとかでDTO（Data Transfer Object）を生成してバリデーションしたいってことあると思うんですよね。
例えば、Java側から外部にリクエストを飛ばすような時って、Service Layerとかでリクエストに必要な情報を作成することになるから、作成した情報をバリデーションするのもService Layerとかでしたいケースとかあるのかなと。
外部から連携された情報でリクエストのDTO（Data Transfer Object）を作成するっていうケースになると思うのだけど。
ネット上をググっていたところ、
⇧ 上記サイト様で、そのものズバリのことについてサンプルを公開してくださっておりました。
見た感じ、基本的には、
- jakarta.validationパッケージ
でバリデーションできるらしいので、Spring Framework以外のフレームワークを利用していたとしてもMVCモデルが実現できるのであればバリデーションの機能をService Layerで実現できそう。
ちなみに、
History of Spring and the Spring Framework
The Spring Framework also supports the Dependency Injection (JSR 330) and Common Annotations (JSR 250) specifications, which application developers may choose to use instead of the Spring-specific mechanisms provided by the Spring Framework. Originally, those were based on common javax packages.
https://docs.spring.io/spring-framework/reference/overview.html
As of Spring Framework 6.0, Spring has been upgraded to the Jakarta EE 9 level (e.g. Servlet 5.0+, JPA 3.0+), based on the jakarta namespace instead of the traditional javax packages. With EE 9 as the minimum and EE 10 supported already, Spring is prepared to provide out-of-the-box support for the further evolution of the Jakarta EE APIs. Spring Framework 6.0 is fully compatible with Tomcat 10.1, Jetty 11 and Undertow 2.3 as web servers, and also with Hibernate ORM 6.1.
https://docs.spring.io/spring-framework/reference/overview.html
⇧ とあるので、Spring Frameworkで、「Jakarta EE（旧：Java Platform, Enterprise Edition (Java EE)）」の機能の一部がサポートされているから、jakarta.validationパッケージの機能が利用できるってことなんですかね。
@Autowiredが、Spring Frameworkの機能なのと、MVCモデルを実現するのに、Spring Web MVCを活用してる感じなんですかね？
そして、MVCモデルはと言うと、
Model-View-Controller (MVC、モデル・ビュー・コントローラ) はUIを持つソフトウェアに適用されるソフトウェアアーキテクチャの一種である。
⇧ Wikipediaの「Model View Controller」の説明のような感じでソフトウェアの構成で役割分担させるためにレイヤーを分ける仕組みということかと。
サーバーサイドだとMVCモデルが一般的な気がするのですが（Spring FrameworkでもSpring Web MVCってあるぐらいなので）、フロントエンド側だと
⇧ 上記サイト様の説明にあるようにMVVMモデルとかも多くなってくるのかなと。
話が脱線しましたが、参考サイト様のようにバリデーションのアノテーションが用意されていない場合は、独自にカスタマイズしたアノテーションを用意する必要があるってことですかね。
Jakarta EE（旧：Java EE）の公式の情報によると、
■Jakarta EE 9
■Jakarta EE 11
⇧ 用意されてるバリデーション用のアノテーションは上記が全量ということかと。
上記で網羅できないバリデーションは独自に作成するしかないようで、
⇧ 上記に独自のバリデーション用のアノテーションの作り方について説明が載っている。
英語圏だと、「全角」という概念が無いのか、仮に「全角のみ」とかのバリデーションが必要な場合は、独自にバリデーション用のアノテーションを作成しなければならないと...
日本語、面倒くさすぎる、というか、システムとの相性が最悪ですな...
とりあえず、Controller Layer以外でのDTO（Data Transfer Object）のバリデーションとかに必要な情報も何となく分かりましたと。
データベースに保存してる情報とかから外部にリクエストする情報を作ったりすると思うんだけど、DTO（Data Transfer Object）のバリデーションをするようにすれば、リクエストする情報のバリデーションができるってことですな。
まぁ、どちらかと言うと、リクエスト送信後のレスポンス受信時のバリデーションの用途が大きい気はしますな。
リクエスト送信の情報は自分たちで作るんだから、バリデーションでエラーになったらそもそもリクエスト送信ができないし、情報を作る時に、IF定義書などを元に正確な情報を設定する実装になるはずですしな。
データベースに保存してる情報を利用するとしても、データベースに保存する時点で不正な値が入らないようにバリデーションしてるだろうし、データベースに保存してる情報を加工するとして設定するにしても、DTO（Data Transfer Object）として完成させる前に正確な情報を設定するだろうからして、DTO（Data Transfer Object）のアノテーションでバリデーションする必要性があまり無い気はしますと。
基本的には、外部システムから連携された値に対して、意図しない値が設定されていないかをバリデーションする用途って感じはしますからな。
毎度モヤモヤ感が半端ない…
今回はこのへんで。
