little-hands / ddd-q-and-a Goto Github PK

Question

他のドメインオブジェクトと同様、ドメインサービスも責務に応じた名前が付けられると思います。

何らかの外部サービスを使って複数拠点間の走行距離を算出するようなサービスに対して、DistanceCalculationServiceではなく、DistanceCalculatorといったServiceが付かない名前でも問題ないでしょうか。

Answer

Question

DDDの導入を検討しています。ユビキタス言語の共有がどうしてもできず、共有を後回しにして値オブジェクト等を作成し始めました。しかし言語を共有していないため、チームメンバーがクラス名を見てもその責務をすぐに理解できません。時にクラスを作った自分でさえ、時間をおくと責務が分からなくなってしまいます（もちろんコードを見ればわかりますが）。現状、DDDでコードを余計に複雑にしてしまった気がしてなりません。やはり、ユビキタス言語を完全に共有することは必須なのでしょうか（共有できないならDDDはスッパリ諦めるべきでしょうか）。

Answer

Question

何かしらの登録画面でセレクトボックス表示用のマスターを取得するのは、CQRSでいうところのクエリサービスでよいのでしょうか？
そのマスターのメンテナンス画面等では、ドメインモデルのリポジトリーなのかなぁと思っています。

Answer

Question

モノリスの分割をしようとしています。まず、(サブ)ドメインを洗い出し、その上にコンテキストを考えようとしています。システムの提供するサービスの機能を見ながら、境界を考えています。どのぐらいの塊で、一つのコンテキストにするべきなのか迷うことも多いです。コンテキスト境界の設計を考える際に、意識するポイントや、思考のステップなどはありますでしょうか？

Answer

大きなシステムの分解については、私も模索中なのであまりはっきりしたことはいえないのですが、あくまで一般論として話します。

・コンテキストの概念的な適切さ
・技術的な適切さ
という二つの観点から並行して検討することになると思います。

概念的な話は、そもそもの意味合いが「同じ言葉、モデルを使い回す境界線」という意味なので、その観点から正しい切り方を考えます。
以前に書いた記事があるのでよろしければご参考にされてください。
https://little-hands.hatenablog.com/entry/2017/11/28/bouded-context-concept

また、技術的な観点としては、例えば細かく割りすぎた時に、joinが大量に発生しそうになった場合は実装時に問題になりそうなことが想像できると思います。そういった点で検討します。

この観点は補完的なものだと思っていて、技術的観点でjoinが大量に発生すぎる、となって考え直して見たら論理的にも切り方が適切ではなかった、ということに気づいたりします。
こういう風に地道に複数観点から検証してその時点の解を出していくしかないのかな、と思っています。

なお、分割する際にはスモールスタートで始めることはオススメしたいです。やはりマイクロサービスの文脈でも切りすぎてあとで大変苦労する話をちらほら聞きます。最初は一つで初めて、同じ単語を複数の意味で使われてややこしくなってきたな、となったらそれはコンテキスト分割のタイミングかもしれません。そのように徐々に進める方が過剰な分割を避けられるのでオススメです。

Question

どの回答も（続く）と書いてあるものの、どこに続きが書かれているのか分からないです。Peingに本文全体を乗せてほしいです。

Answer

基本回答は全部twiterの方に寄せているので、 タグで辿ってもらえると過去のやつがみれるようになってます！

Question

自分はサーバサイドでRailsしか扱ったことがありません。
DDDを勉強・活かすのにオススメの言語・フレームワークがあったら教えて頂きたいです。
稚拙な質問ですがよろしくお願いします。

Answer

勉強という意味では、php、Laravelあたりはいかがでしょう。DDDをやってみたという情報は多いのと、rubyからのとっつきやすさ観点です。
向いているという意味では、型をきっちり意識しながらコーディングするのが大事なので、基本的には静的型付け言語が向いています。Java、C#、goあたりですね。タイムリーですが成瀬さんの本はサンプルコードがC#です。
https://twitter.com/little_hand_s/status/1224660909076836352?s=21

私は普段JavaでSpringを使っていますが、一通りDDDで開発するのに必要なものは揃っており、やりにくい制約などないので、問題なく開発することができます。

Question

ツイッターを無断で書籍にしてもいいですか？

Answer

…！？
ダメなのでは！？笑
一言連絡もらえれば嬉しいですw

Question

システム的に、ユーザーアカウント登録で仮登録→本登録の流れがある場合、仮登録ユーザーと本登録ユーザーは分けるべきでしょうか？

Answer

Question

ツィッターフォローさせてもらってるものです。
まだ、ドメインモデルというものがピンと来てないです。値オブジェクト、エンティティは分かるのですが、いざ画面を作るとどこかドメインモデルになるのか分かりません。

値オブジェクトやエンティティの集合体と考えていいのでしょうか？
逆に言えば、モデル=画面に表示したりするもので良いのでしょうか？

Answer

サーバーサイド前提で話をすると、エンティティ、値オブジェクトとして設計されたものは最終的にサーバーサイドのクラスとして実装されます。1エンティティ1クラスです。
画面にはそれらのクラスの値を詰め替えたものを表示する形になるので、画面に表示するもの自体がドメインモデルにはなりません。

Question

すいません、先ほど質問に訂正します。システム的に、ユーザーアカウント登録で仮登録→本登録の流れが有る場合、仮登録ゆーざーエンティティと本登録ユーザーエンティティは分けるべきでしょうか。

Answer

まず、この実装はモデリング結果に依存します。ドメインモデル図で別のオブジェクトとして書いたら実装も別に、同じオブジェクトの状態が変更される、という形でルール/制約を吹き出しに書いたら同じオブジェクトです。実装の細かい制約は抜きに抽象的なモデル図を書いたときに、どちらの方が捉えやすく、しぜんでしょう？もしよかったらその回答もお聞かせください。

Question

Rubyでドメイン駆動設計は実現できますでしょうか？

Answer

型がないとなかなか厳しい気がしています…！
いきなりですが、@minodriven さんいかがですが？笑

Question

よく例とかで金額にはマイナスの値は入らないので、そのチェックをドメイン層のコンストラクタ時に知識を移譲すると思いますが
microserviceでgrpcを使用した時に、grpcの通信時に金額マイナスのチェックを行っている場合、ドメイン層のコンスタラクタ時にも同様のチェックをすべきなのでしょうか？

Answer

優先すべきはドメイン層のバリデーションで、プレゼンテーション層(この場合はgrpcのリクエストを受けるコントローラー)のバリデーションは必要に応じて追加、というのがよいと思います。

ドメインの入力ルールというのは重要で、確実に守りたいものです。これがドメイン層にない場合は、ある処理ではバリデーションされますが、別の処理ではバリデーションを忘れた、といった場合に整合性が保証できなくなります。そのためドメイン層のロジックとして実装に、それ以外の層からは整合性を破壊できないようにすると安心です。そのため、プレゼンテーション層よりもドメイン層のバリデーションは優先したいです。
一方、同じ内容のバリデーションをプレゼンテーション層で実装する必要があるのでしょうか。一つはAPIの仕様として外部にリクエストのルールを公開する場合、そのロジックはプレゼンテーションで明示的に管理したい、というケースです。この場合はAPIのバリデーション仕様が明確ななるというメリットの代わりに、ドメイン層のバリエーションが変更になった時に手動で追従するコスト、見逃すリスクが発生します。
また、プレゼンテーションとしてフロントエンドモジュールも含める場合、UXのために同じ内容のバリデーションをフロントにも書くことはあります。これはサーバーにリクエストせずにキー入力のタイミングでバリデーションをかけるなど、素早くバリデーション結果をユーザーに提示したい場合などに検討されます。これとUXと引き換えにドメイン層と乖離するリスクがあります。
ここまでのメリットデメリットを考慮して、どのような選択をするかを決めることになります。

Question

直接DDDの質問ではないのですがよろしければ教えてください。
clean architectureでwebサービスを作るときに、複数種類のデータ表示が1ページに入ることが多くユースケースが肥大化してしまい困っています。解決策をご存知でしょうか？？

Answer

DDD関係なくても大丈夫ですよ！案1としては、1つのユースケースクラスからある程度責務を独立させられそうなオブジェクトを切り出します。

例えば、データAを取得する処理はDataAFetcher、変換する処理はDataAConverter…という風に(fetcherのネーミングは微妙な気もしますが一旦例として…)
これはprivateメソッドで切り出すことは多いと思いますが、それをすると1クラスが多数のprivateメソッドで膨らんでしまいます。
そうではなくデータAを取得するという責務を持ったクラスして切り出してしまうことで、クラスの凝集度が上がり保守性が高まります。
特にテストはやりやすくなり、それらの独立したクラスそれぞれで単体テストを行い、ユースケースクラスはそれらを組み合わせる観点のテストだけ書けばよくなります。(余談ですが)テストのしやすさを追求することは、良い設計を追求することにも結果としてつながるという好循環が生まれます。

この独立させたクラスは、ユースケース層内オブジェクトという位置づけがよいでしょう。プレゼンテーション層から呼ばれるものはユースケースクラスで、ユースケースから呼ばれる用途限定の独立クラスという位置付けです。
階層化するために、ユースケースを複数呼ぶ方向性もありますが、凝集度を上げられないのであまりお勧めしません。

もう1案は、CQRSの検討です。概要、検討観点は以下のブログに書いたので、参考にしてみてください。
https://little-hands.hatenablog.com/entry/2019/12/02/cqrs

Question

オニオンアーキテクチャで、トランザクション処理はどの層でかけるのが適切だとおもいますか？

Answer

Application層がオススメです。
実践DDDにもそう紹介してあり、やって見るとしっくりきます

Question

ユースケース層のクラスはユースケースのステップを実現するためのアクションをクラス化するのでしょうか？タスクを追加するユースケースでは、タスク登録画面用の初期化で使うセレクト（優先度や緊急度）の取得、オペレーターが入力した内容の作成の2つがユースケース層候補でしょうか？確認画面などがあった場合は更に追加になるのでしょうか？

Answer

はい、ご認識の通りだと思います。
「ユースケース層はユースケースを実現するのが責務」とは言いますが、実際はhttpリクエストが複数になる場合はその単位で分かれることになります。
ユースケース1つに対応しているかというより、"ドメイン層で公開されたメソッドを組み合わせて"ユースケースを実現するというところが重要ですね。

Question

ツイッターフォローさせていただいてます。DDDで設計をした場合、beansやDTOは不要になるという事は理解しています。しかし、弊社で使用しているフレームワークではDTOの使用を前提としたものになっているのですが、DDDで設計をする上で上手なDTOとの付き合い方はないものなのでしょうか？

Answer

BeansやDTOというのは何を表すでしょうか？DDDの、クリーンアーキテクチャをはじめとしたレイヤーを持つアーキテクチャでは、(略)

Question

基本的に、ドメインモデルのフィールドは、DBにおける該当テーブルのカラムと1対1で対応するという認識は合っていますか？

Answer

Question

UseCase層のクラスの命名規則や、UseCaseを実行するメソッドの命名規則について、お決まりの物がありましたら教えてください。

Answer

Question

QueryServiceで取得したDTOは、コントローラ側でテンプレートエンジン用のViewModel、Json変換用または(CSV等の)ダウンロード用クラスなどにコピー/変換するイメージでしょうか。

Answer

Question

DDDにあるようなオブジェクト指向を駆使し、データとルールをカプセル化してビジネスルールを表現するのと、BRMSのような、データはデータ、ルールはルールで分けてビジネスルールを表現するのとでは、最終的にルールの変更に対してどちらが有利だと思いますか？

Answer

【ゆる募】BRMSを知らないためお答えできず…どなかご存知のためご回答いただけませんか

Question

アプリケーションサービスでリポジトリよりドメインオブジェクトを受ける際、存在しなかったら例外を投げると言った場合、チェックして例外を投げる処理はアプリケーションサービスで記述するのでしょうか。

チェック用のドメインサービスを噛まして、取得できた場合のみアプリケーションサービスで受け取ると言った方法も考えられます。

業務要件により処理が分岐する場合はアプリケーションサービスで記述した方が良さそうですが、そうでない場合はノイズが増えるだけに思えて下の階層で処理した方がいいのでは無いかと迷っています。

Answer

Question

こんにちは。
クエリサービスクラス内で、ファクトリークラスを使用し整形・作成した配列をユースケースへの戻り値とするのは良いでしょうか？

Answer

Question

ドメインサービスが直接RepositoryやAdaptorを扱うのは一般的でしょうか？なんとなくアプリケーションサービスの領分な気がしているのですが

Answer

原則は「オブジェクトがどのレイヤーに所属するか定義し、その依存関係に従う」です。

Question

DDDの進め方において、コアドメインに集中してDDDを進めると言うのがあると思います。

サブドメインやマスタメンテのようなCRUD処理についてはトランザクションスクリプトで書いても問題ないということだと思いますが、一つの開発プロジェクトにDDDとトランザクションスクリプトで実装した処理を混在させて混乱が生じたりしないのでしょうか。

Answer

何もルールがなければ混乱すると思います。DDDのルールを適用する/しないの判断基準、それを実装する場合のルール(パッケージとか、アプリ自体わけるとか)を明確にし、言語化しておくことが必要だと思います。
実践DDDとしては、ドメインごとにコンテキストが異なることが良いとかかれています。これはつまりコアドメイン、サブドメインを明確にわけ、アプリケーションやモジュールの単位で、わけてしまうということです。
これに則ると、同じドメインの中で簡単だから、複雑だからという基準でわかるのはあまり推奨されていないように思います。

Question

集約内に、クイズ一問の選択肢を用意してリストに入れたり答えを返したりする処理を持つクラスだけがあります。
これってドメインサービスなのでしょうか？
IDで識別するものではなく中身を変える必要もないので、エンティティでも値オブジェクトでもなさそうに思えます。
でも集約にはエンティティがあるものですよね…？

Answer

クイズ集約のなかに、クイズという集約ルートエンティティと、その選択肢という値オブジェクトがあるという設計はいかがでしょう。
そうすると、ユースケース(アプリケーションサービス)はクイズ集約の値を取得して詰め替えるような処理になると思います。その場合は特にドメインサービスがなくてもいいですね。

Question

ドメインオブジェクトをリポジトリパターンでSaveメソッド、deleteメソッド実行した場合、
ドメインオブジェクトの子、孫要素まで、保存、削除を行うという風に理解(理解が間違っているたらすいません。)しているのですが、
子、孫の要素のみを保存や削除をする場合は、子、孫単位でリポジトリを作成する方が良いのでしょうか。
(#ドメインオブジェクトとして、子、孫は、必ずしも存在しなくても良い状態(コンポジションではない)です。)

そうなるど、集約の単位よりは、コンポジションの単位でリポジトリを作成すべきなのでしょうか。

Answer

save, deleteに関しては、ご認識のとおりです。ただ、孫だから別に、と一律決めるより、モデリングした時に整合性を守りたい強さで集約の範囲を決める方が自然です。ただ、今回は必ずしも存在しなくてよい、と言われているので、モデリング的にも別集約でもよいのかもしれません。正確な答えは具体的なことを聞かないとわかりませんが、今ある情報からの一般論として、という形にはなります。もうすこし具体的に書いていただければ具体的に答えられるかもしれません。

Question

DDDの腐敗防止層について質問です。
IDDD本のp447~ではDomainServiceをインターフェース化し、Infra層の実装でAdapterを使っていますが、RepositoryのようにAdapter自体をif化しないのはなぜでしょうか。
そちらの方が、ドメインロジックをドメインサービス内で合わせて使いたい場合など、責務分離しやすい気がしてしまいます。

Answer

この場合は、adpterがドメインサービスのIFに対する実装方法の一つという位置づけで、インフラ層に閉じ込めてほかの場所で再利用させない、という方針だからだと思います。

Question

今の現場でオブジェクト指向の限界(参照透過性の問題やクラスの増大)を問われ、関数型プログラミングを強要されそうなのですが、(関数型に比べて)オブジェクト指向の強みって何でしょうか？

Answer

関数型はきちんとやったことがないので役に立つ回答はできません、すみませんm(_ )m
オブジェクト指向はモデル図の形をそのままコードに落とすには向いていると思いますm( _)m

Question

DTOがクライアントに依存しないことと、DTOがユースケース特化型であることは両立しますか。

Answer

Question

Object-Oriented Conference 2020のスライドについて質問です。
スライド98では、TaskApplicationServiceクラスが、TaskRepositoryクラスを生成しています。
TaskRepositoryクラスはどこの層で定義されているのでしょうか？

インフラ層だと思うのですが、すると依存関係がおかしい気がしてモヤモヤします。
https://little-hands.hatenablog.com/entry/2020/02/17/ooc

Answer

リポジトリはインターフェイスがドメイン層、実装クラスがインフラ層です。
そうすると、アプリケーション層(ユースケース層)からはリポジトリの実装の詳細(なんのライブラリを使っているか、DBの構造など)を知らずに、インターフェイスに定義されている知識の「Taskという単位で永続化できるんだ」ということだけ認識することができます。

Question

ユースケースクラスで、業務ルール違反でExceptionをスローした場合、画面にエラー内容を表示したいというケースを想定しています。
どこでキャッチすべきでしょうか？
ユースケースでキャッチする場合は、コントローラーてで処理結果の判断が必要になり違和感を感じます。
かといってコントローラーでキャッチするのも違う気がしています。
漠然としていて申し訳ありません。

Answer

Question

DDDを実践したいです。参考になるgithubのリポジトリを知りたいです

Answer

パッと出てこないので募集します！良いレポジトリご存知の方、自薦他薦問いません、およせくださいーー！m(_ _)m

Question

CQRSで迷ってることで質問です。
WEBアプリケーションでアカウントを編集画面で編集前のデータを取得する時は
commandでやるべきですか？Queryでやるべきですか？編集したデータを更新する時はCommandだと思いますが。

Answer

Question

WebAPIのクエリパラメータの数がたくさんある場合、どの層で各パラメータをオブジェクト化してまとめるのがベストでしょうか？
(各層のメソッドを呼び出す度に引数に全パラメータを書くのはとても冗長ですが、とは言えオブジェクト化の知識をどこに置くべきかわからずに悩んでいます)

Answer

呼び出される側のレイヤーから順番に考えていき、オブジェクトを定義するのが適切と考えられるところでまずオブジェクトを定義します。そのレイヤーを呼び出すところからは、そのまとめたオブジェクトを利用するのか、それとも自分のレイヤーで再度オブジェクトを定義するのかを選びます。

Question

DDDで設計して、実装はクリーンアーキテクチャでやろうと考えています。
クリーンアーキテクチャで実装する際にも、有用な戦術的設計のパターンありますか？

Answer

普通にDDDで定義されているパターンがそのまま使えますよ！
エンティティ層と定義されているものをドメイン層と読み替えて、そこにエンティティ、値オブジェクト、リポジトリのインターフェイスなどを定義します。
ユースケース層ならアプリケーションサービス、アダプター層にはリポジトリの実装クラスを定義します。これで矛盾なく実装できます。

Question

ドメインとはなんですか。

Answer

ソフトウェアで問題解決しようとする対象のことをそう呼びます。

Question

エンティティのコンセプトは理解できますが、実際どう使うかが値オブジェクトと比べてイマイチわかりません。DBの候補キーとなり、insert,select時に使うのでしょうか？また、可変な属性はいくつまで持たせていいのでしょうか？

Answer

以前にエンティティと値オブジェクトの違いについて記事を書いたのでそちらを見てみてください。

https://little-hands.hatenablog.com/entry/2018/12/09/entity-value-object

属性について、個数の制限というのは特にありませんが、多いと感じたら常に分割できないかは考えてみると良いでしょう。個数は特に決まってないですが…10個もあったら多いとは思います。

Question

ドメイン駆動設計に入門しようと、エリック・エヴァンスのドメイン駆動設計を本屋でパラパラめくってみたのですが、自分にはレベルが高すぎると感じています。
上記の本より前に読むと理解がしやすくなるような本があったりしたら嬉しいのですが、気合いを入れてエリック本を読むのが良いでしょうか？

Answer

エリック本はとにかくお勧めしません。初心者キラーです。
初心者フレンドリーとは言いにくいですが、今の所実践DDDが一番いいですかね。。
つまづいた時はDDDコミュニティで質問すると結構すぐに答えが帰ってくるので、よろしければご活用ください！
https://twitter.com/little_hand_s/status/982979772157313025

Question

メール送信処理はどの層にどのように書くべきでしょうか？

Answer

ドメイン層に「EMail」クラスと、「EmailSender」インターフェイスを書きます。EmailSenderの実装クラスはインフラ層に書きます。EMailクラスは送信方法によらずに抽象的な情報だけ持つようにします。
よくあるのが「EMailSendService」と言ったクラスに「どのようなメールを組み立てるか」という実装と「なんの方法でメールを送るか」というのを両方実装してしまうパターンですが、その二つは異なる責務として切り分けて別のクラスに切り出すと非常にメンテナンス性が高まります。

Question

ブログを拝見して、オニオンアーキテクチャから試してみています。
ある程度オニオンアーキテクチャは理解できたのですが、クリーンアーキテクチャにおけるusecaseがどういう役割を持つかが未だによくわかりません。
オニオンで言うApplication Serviceがuser caseとほぼ同じといった認識であっているのでしょうか？

Answer

ほぼ同じという認識で良いと思います。プレゼンテーション層とインフラ層にアプリケーション外とやり取りする責務を持たせ、ドメイン層にドメインモデリングしたドメイン知識(ルール、制約)を表現する責務を持たせると、残りの方にはアプリケーションとしてユースケースを組み立てる責務が残ります。
これはユースケース層もアプリケーション層もほぼ同じことを行うことになると思います。

Question

DDDに関して質問です。
DDDでDBからSelectして返すような処理をRepositoryで実装しようとしています。
その場合Repositoryにinterfaceをはやして、Entityで返すのが実装方法として考えられると思いますが、
そのinterfaceでは不要なカラムもEntityに合わせて一緒のDBから取得しないといけないのでしょうか？ただ不要なデータをDBから取得するのでパフォーマンスが悪くなるかと思います。
このようなケースはDTOを使ってRepositoryからの返り値をDTOで返すような実装になるのでしょうか？

Answer

まさにそのような問題への対応としてCQRSというものがあります。こちらの記事をどうぞ！
https://little-hands.hatenablog.com/entry/2019/12/02/cqrs

Question

DDDを新人に一言で説明するとしたらどのようなものだと説明しますか？

Answer

「綺麗なコードを書く」と「役立つものを作る」を実現するための手法です。

Question

排他制御ってアプリケーションサービスでトランザクション管理するときに分離レベル指定してやったらすると思うんですけど、行ロック取りたくなった場合もアプリケーションサービスの責務ですか？

Answer

私の場合は、になりますが、アプリケーションサービスでトランザクション開始とその後のコミット/ロールバック決定は責務として持ちますが、クエリで行うようなロックの指定に関してはRepositoryの実装クラスでおこないます。

Question

少し前に話されていたアジャイルの技術部分のコミュニティに興味があります 。私自身勉強通の身なのでお役にたてるかわかりませんが、是非お協力したいです

Answer

社内で一度開催予定で、年明けに検討しているのでまた告知します！お待ちくださいー！

Question

松岡さんのCQRSの記事を見ながら挑戦してみている者です。質問なのですが、CQRSの記事内でUseCase層に実装しているDTOのプロパティではDomain層のValueObjectを利用してもよいものなのでしょうか？ケースバイケースかもしれませんが、松岡さんの考えを教えていただければと思います。

Answer

原則としては、させないほうが良いとは思います。なぜかというと、DTOに表示用のメソッド(書式変換など)を持たせようと思った時に、ドメイン層のオブジェクトをそのまま使用していると、ドメイン層のオブジェクトには不要なメソッドを生やすことになります。このような実装は一度許すと後から同様の責務違反を誘発するきっかけになりす。これが重なると凝集度が下がり、保守性を下げる原因になります。

とはいえ明らかに重複したもの、例えば
enumとかは毎回別途作るのは無駄に感じる時もあるとは思います。その場合は上記のリスクを十分か考慮して使い回すということもありだとは思います。ただ、往々にして後から「分けておけばよかった…」となるものなので、そこはお気を付けてください。笑

Question

ただDBからSelectしてそれを返すようなエンドポイントで、返り値用のDTOを作成してRepositoryから返すようにしているのですが、そのときにDTOのフィールドにはVOを使ってもよいのでしょうか？

Answer

二つの論点があると思います。
■リポジトリから戻り値用のDTOを直接返すことについて
これはCQRS(更新系のモデルと参照系モデルの分離)と呼ばれるものになります。
その際、更新系のモデルのDBアクセスに使うクラスであるリポジトリが、参照用モデルを返してしまうと、責務がぶれてしまいます。また、参照用の最適な型はユースケースによって異なるので、ドメイン層ではなくユースケース層(アプリケーション層)に定義すべきです。
そのため、CQRSとして参照用のモデルの戻りの型とdbアクセス用のインターフェイス(私はQueryServiceといった名前をつけます)をユースケース層に、QueryServiceの実装クラスをインフラ層に書きます。
CQRSについては以下の記事もご覧ください。
https://little-hands.hatenablog.com/entry/2019/12/02/cqrs
■参照用DTOに値オブジェクトを詰めて良いか
参照用と更新用できっちりモデル(クラス)を分ける方がよいです。使い回すと、参照用のメソッド(例えば書式の変換など)が、更新用のドメインオブジェクトである値オブジェクトに書かれてしまうようなことを誘発します。

クラスの責務(それは何をするクラスなのか？)をしっかり考え、その責務なら外れた処理を書かないように気を使っていくことが大切です。

Question

各パラメータを、1つの配列にまとめる意味合いです。
現在アプリケーション層からインフラストラクチャ層のメソッドを呼び出す際に1つの配列にまとめて渡していますが、前段階のプレゼンテーション層からアプリケーション層に渡す際は全パラメータを1つずつ引数に入れている状況です。

Answer

Question

テーブルのIDカラムがAutoIncrement型の場合、EntityのidフィールドはNullableにしますか？
RepositoryのinsertメソッドにEntityを渡すとき、insert時はidがないのでEntityをどのように定義すればよいか悩んでいます。

Answer

これは悩ましいですよねー！
RDBにID採番を任せる場合はこの問題に突き当たりますよね。
解決策としては(Javaの場合)フィールドはnullableだがgetterはnullable扱いしない(Optionalでラップしない)、nullの状態で値を取得しようとしたら実行実行時例外。その場合呼び出し方の呼び出し順が正しくないのでバグ扱い、という解釈が一番意味が通るかなと思います。

Question

DDDのオニオンアーキテクチャが所謂モダンWebアーキテクチャ（React、Spring Boot、RDBMSを使ったもの）との相関が不明です（DDDのどのレイヤをどの技術で実装するか）。
明確な回答ありましたらお願いします。

Answer

aaa

Question

インターフェースの定義について教えてください。単体テストを実施しない、かつインターフェースの実装を交換したりしない場合、インターフェースの定義のメリットはありますか？

Answer

その場合、レイヤーの責務を明確に守りたい場合に使えます。例えばオニオンアーキテクチャでは、リポジトリのインターフェースはドメイン層に、実装クラスはインフラ層に定義します。そうすることで依存の向きがインフラ層からドメイン層の向きにすることができます。これを依存関係逆転の原則と言います。
これを用いて、ドメイン層やユースケース層は特定のインフラ知識(どのデータソースを使うとか、ORMを使うとか)に依存しない書き方にすることができます。