В dto запроса нужно получать лишь id сущностей агрегата, а дальше мапаешь dto в entity и сохраняешь в репозиторий.

Чтобы получить id сущностей, нужно сделать findBySomething (или выражаясь через sql, сделать SELECT), это можно делать, да. Но проблема появляется (или нет?!), когда я не знаю изначально id и не знаю записана ли вообще нужная мне сущность. Предположим есть структура данных Блюдо -> 1 ингредиент -> 1 категория. Я не знаю есть ли такой-то ингредиент в базе. Если его нету, то надо бы вставить новый ингредиент и по хорошему бы сделать вставку блюда, ингредиента, категории в одной транзакции.

или я не правильно понимаю?

Ингредиенты сохраняй отдельно от блюда. Твой DishRepository не должен заниматься сохранением ингредиентов. DishRepository и IngredientRepository  должны быть независимы. Пусть юзер сначала создаст ингредиент, а потом уже оперирует ими в создании блюда.

И в dto нужно id ингредиентов, а не названия.

планировщик будет соответственно с приоритетами  потоков(по умолчанию наследуется приоритет процесса) выдавать им кванты времени, соотв на ядре в определенный момент времени будет работать один поток, потом произойдет переключение контекста планировщиком и на ядре начнет работать другой поток.

Ну хорошо, а что если мне все же нужно будет вставить все за раз? т.е. вставив, ингредиент, я не хочу, чтобы он был дальше в базе, если не получилось вставить блюдо.

Почему тебе нужно вставить всё за раз?

У тебя составные блюда - справочные значения

Которые должны в виде айди прилетать в дто

Я предполагаю, что возможен реальный случай, когда нужно вставлять какие-то сущности за раз

возможно тут мне и не нужно

это скорее для того, чтобы понять что к чему

Я вижу решение такое, что будет DishService, в котором будет большой транзакционный метод, который будет привязан к DishRepository, IngredientRepository ... и внутри метода (еще не уверен как это сделать) сохранять новые recordы. Но это пахнет костылем

Какой случай? Если так действительно тебе нужно это, то пусть этим занимается клиент. Фронт сделал запрос - проверил, есть ли ингредиент с таким названием. Есть - взял id, нет - создал, взял id. Позже шлёшь запрос на создание продукта со стянутыми id.
Второй варик - ингредиенты как value-object, тогда вообще не будешь об этом париться.
Но оба варианта нахер не нужны, поверь.

Ну и советую глянуть, зачем нужны дто, можешь чекнуть реальные проекты.

Доверить клиенту напрямую создавать что-то в ДБ не очень хорошая идея, почти любой клиент через пару месяцев утонет в засранной им де номенклатуре

Можно делать в это сервисе, но лучше не надо.

Я не говорю напрямую всё и всегда создавать в бд. Однако, если в с каждым запросом проверять наличие ингредиента по названию, то нагрузка сильно возрастает, т.к. это не select by pk.

могу сделать название ингредиента pk