3/6

はい、タイプセーフになる利点はその通りです。あとはドメインオブジェクトの責務に該当するものをきちんとクラスに閉じ込めると高凝集、低結合になります。高凝集、低結合になると一般に保守性が高まります。高凝集、低結合に関してはこちらの動画もどうぞ。 https://www.youtube.com/watch?v=-JOravz-qoU

Answered questions

値オブジェクトについて質問です。
ビジネスロジックが無く、文字数制限だけしかないプロパティも値オブジェクトで作成すべきでしょうか？

例えば、タスクEntityの「タスク名」プロパティは今のところ100文字の文字数制限しか制約を想定していないため、LimitedString100のような値オブジェクトでも良いのでしょうか？

エンティティのID生成はドメイン層の関心ごとか、インフラ層の関心ごととするか？
前提として、DB保管時にauto_incrementやsequenceで発行されるIDではなく、モデルごとにuuidのようなIDを発行します。

質問です。

タスクを登録するロジックに関して、
タスクの名前は重複してはいけないという制約があるとします。
この制約はどのレイヤで記述すべきですか？
1. ドメイン知識であるからドメイン層？
2. DBに問い合わせる必要があるからインフラ層？
3. 上記どちらでもなくユースケース層？