У меня есть createDto, в которой контракт, что нужно, чтобы

создать сущность, но при этом есть данные, которые мне нужно получить из другого сервиса, чтобы создать сущность. Но в круд-сервисе было бы не очень здорово идти в другой сервис, это не его ответственность, т.е мне либо нужно создать еще одну createDto, но не хочется плодить сущности, либо передавать в круд и createDto и сущность, которая нужна для создания и в круде их джоинить. Как лучше поступить?

createDto должно прилетать не в круд-сервис, а на сервисный слой, а там уже и другие сервисы можно использовать

Понятное дело, что оно туда прилетает, но сущность создается ниже, именно в круде

Если у другого сервиса есть api - сгенерировать по нему классы Саму логику вынести в сервис

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

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

Вопрос был не об этом, либо я вас не поняла

сделайте сервис, который будет принимать все ваши параметры и DTO. этот сервис подготовит все исходные данные и передаст их в ваши CRUD сервисы. т.е. вам нужно как минимум сервисный слой еще реализовать. который будет делать какуюто работу, прежде чем чтото сохранять. CRUD не должен обрабатывать бизнес логику

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

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

Я и говорю, что это плохая идея, так как не его ответственность, поэтому ходить в другой сервис будет сервисный слой, который выше. Что значит, куда смотрит круд? Никуда не смотрит, ходит в репозиторий и все. Стек непринципиален, но вообще котлин+жук, ну и спринг соответственно

Анастасия спрашивает, как быть. Нужно ли для дао сделать ещё одну дто(свою) или передавать две дто со слоя сервисов.

Да

Я бы сделал свою дто в дао, как только первое изменение и неконсистентность между данными дао и тем, что приходит в сервисы, т.к. если будет меняться мапинг в слое сервисов( переименовываться атрибуты например) то дао будет страдать. Хотя ей должно быть все равно. Но для начала срезал бы угол - проще не делать, пока нет в этом нужды. Это не архитектура, которую будет сложно поменять в будущем

Что такое дто в дао?)

Контракт Дао - какая то дто, на основе которой она уже создаёт запись в бд. Аналог entity, если dao jdbcTemplate например. Или можно как-то по-другому?

но это это странно. значит сделать новую таблицу в БД(репозитарии)?

Да, но я к тому что дто обычно не внутри дао Или я просто такой реализации не видел)

помоему я догадался о чем вы говорите. у вас прилетает бизнес сущность в виде DTO + еще какието метаданные возможно. вам их нужно положить в базу, но не в одну таблицу, а в несколько связанных. угодал?)

Тоже примерно так и думала, спасибо

Нет, сверху Владислав повторил, что я имела в виду