Через саппорт метод и теггед итератор, посмотрите реализацию нормалайзеров в сериалайзере

Можно и без саппорт метода

Как? Типо фабричный метод который Return null or object?

да по разному, например в argument value resolver теперь нет метода саппорт, метод resolve решает резолвить аргумент или нет, возвращая либо пустой массив либо массив с объектом

Всем привет! Кто-нибудь использует http код 422 при формировании ответа? Никак не могу уловить, в чем отличие от 400

400 - данные не валидные, 422 - данные ок, и мы пытаемся сделать что-то, но не получается https://www.rfc-editor.org/rfc/rfc9110.html#name-422-unprocessable-content

Ну нет же

Причем видимо тело не ок в смысле не валидность данных, а например битый джсон или хмл неправильно отформатированный

Всем привет. Расскажите про ддд немного? точнее про ограниченные контексты. Если при изменении внутри агрегата необходимо в рамках одной транзакции изменять другой агрегат - это результат неправильного проектирования? Пример: Есть агрегат заказа , при смене статуса которого надо пересчитывать рейтинг пользователя. Как тут быть? Пользователь с его рейтингом должен быть внутри агрегата заказа? или Агрегат с юзером должен реагировать на событие смены статуса заказа? Но для пересчета рейтинга пользователя надо опираться на заказы - т.е. опять таки пользоваться контекстом заказа.

Всем привет. Расскажите про ддд немного? точнее про ограниченные контексты. Если при изменении внутри агрегата необходимо в рамках одной транзакции изменять другой агрегат - это результат неправильного проектирования? Пример: Есть агрегат заказа , при смене статуса которого надо пересчитывать рейтинг пользователя. Как тут быть? Пользователь с его рейтингом должен быть внутри агрегата заказа? или Агрегат с юзером должен реагировать на событие смены статуса заказа? Но для пересчета рейтинга пользователя надо опираться на заказы - т.е. опять таки пользоваться контекстом заказа.

Всем привет. Расскажите про ддд немного? точнее про ограниченные контексты. Если при изменении внутри агрегата необходимо в рамках одной транзакции изменять другой агрегат - это результат неправильного проектирования? Пример: Есть агрегат заказа , при смене статуса которого надо пересчитывать рейтинг пользователя. Как тут быть? Пользователь с его рейтингом должен быть внутри агрегата заказа? или Агрегат с юзером должен реагировать на событие смены статуса заказа? Но для пересчета рейтинга пользователя надо опираться на заказы - т.е. опять таки пользоваться контекстом заказа.

Если при изменении внутри агрегата необходимо в рамках одной транзакции изменять другой агрегат - это результат неправильного проектирования? Да. Но в твоем примере это разные транзакции всё-таки. Пример: Есть агрегат заказа , при смене статуса которого надо пересчитывать рейтинг пользователя. Как тут быть? Пользователь с его рейтингом должен быть внутри агрегата заказа? Не должен, они разные же. Да и рейтинг пользователя не должен знать ничего про заказ, как и заказ про рейтинг пользователя(наверное, могут быть нюансы) Решается ивентами. Тип при смене статуса бросаешь ивент, на который подписан хендлер с пересчетом рейтинга. Через мессаджи какие. Кафка, хуяфка, кролик, шмолик... етц. или Агрегат с юзером должен реагировать на событие смены статуса заказа? Но для пересчета рейтинга пользователя надо опираться на заказы - т.е. опять таки пользоваться контекстом заказа. Типо того. Запросишь у сервиса заказов список заказов юзера да пересчитаешь. Через интерфейсы, или через веб интерфейсы, или как там хочешь.

Всем привет. Расскажите про ддд немного? точнее про ограниченные контексты. Если при изменении внутри агрегата необходимо в рамках одной транзакции изменять другой агрегат - это результат неправильного проектирования? Пример: Есть агрегат заказа , при смене статуса которого надо пересчитывать рейтинг пользователя. Как тут быть? Пользователь с его рейтингом должен быть внутри агрегата заказа? или Агрегат с юзером должен реагировать на событие смены статуса заказа? Но для пересчета рейтинга пользователя надо опираться на заказы - т.е. опять таки пользоваться контекстом заказа.

Еще момент важный - главное не упарываться в ДДД. Например заказ, у вас там может быть круд, чтобы положить инфу и 0 логики.

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

Смена статуса происходит ж не сама по себе. Вот и например есть команда ShipOrderCommand и меняй там себе ордер и юзера

Воркфлоу же не про ивенты, а про контроль стейта, чтоб не прыгали через этапы какие-то

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

Вообще уходить нало от круд модели

А никак не должно по идее

Ага. Поменяли заказ, статус апдейтнули. Почему? Зачем?

Так, вернемся) Т.е. у вас команда - это то что намешано из разных контекстов?

Атомарный юнит изменения состояния системы

Т.е. она может репозитории в себе хранить. Вот тебе и твой контекст сохранен

Да команда вне контекста

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

Ну вот ты пришел с этим вопросом сюда почему?

Я такого не писал )

Мне главное что есть место в котором можно увидеть все бизнес операции

Если модули независимо должны работать и они больше как плагабл фции да команды не подходят