Разве не странно что репозиторий у вас прокидывается в Handlers? Я думал в том то и смысл, что условно репозитории незнаю про внешнию логику, а в handlers мы используем только UseCase/Service, который под капотом сами уже работают с repo.
16:51 как сохранить транзакционность запроса к приложению, если за счет интерфейсов мы ходим отдельно в разные репы в свои реализации на уровне домена с одиночными запросами, и делаем сохранение Ордера, но сохранение Продукта допустим у нас ломается? Получится что у нас сохранился ордер, а продукт отвалися по неизвестной причине, карточный домик посыпался получается?! Или не вижу всей картины?
Есть паттерн типа Unit Of Work, которая оборачивает несколько репозиториев, чтобы сделать коммит, только когда они все завершили операции. Но это не лучшее решение, т.к. UoW живет на уровне сервисов и абстракция хранения данных неявно протекает
@@IvanIvanov-re8bk как вариант не использовать репозитории) для многих микросервисов абсолютно нормально писать код бизнес логики и походов в бд прямо в хэндлере. Пусть будет хэндлер на 50 строчек, это помещается на экран и с этим можно будет в дальнейшем разобраться другому человеку. И транзакции можно будет легко настроить
Чот смешал много в кучу. Сущности как будто частично срастил с vo, dto откуда то - это не вид объекта, а просто назначение некоторых vo. Слои вольно поданы, ну хотя бы есть. Инфра инжектирована прямо в представление (если 500 строк сервис, конечно, чо бы нет). Вобщем вольная трактовка ддд как некоего элемента слоёной архитектуры с намеком на чистую
За видео спасибо. Но вопрос к оператору - а зачем в произвольные моменты переключать вид из камеры? Это же не "Матрица", достаточно простого вида "в анфас".
Классный доклад! Все просто и доходчиво. Спасибо
Спасибо! Интересный и полезный доклад :)
Разве не странно что репозиторий у вас прокидывается в Handlers? Я думал в том то и смысл, что условно репозитории незнаю про внешнию логику, а в handlers мы используем только UseCase/Service, который под капотом сами уже работают с repo.
Обожаю DDD, как го.
Лучшее комбо
на большом проекте все это дело превратиться в кашу, даже с ddd лучше использовать подход по разделению by feature
open-closed - не про изменение извне, это про то, что спроектирован изначально так, что открыт для расширения и закрыт для изменения логики
Не одним агрегатом мы едины! 😂
16:51 как сохранить транзакционность запроса к приложению, если за счет интерфейсов мы ходим отдельно в разные репы в свои реализации на уровне домена с одиночными запросами, и делаем сохранение Ордера, но сохранение Продукта допустим у нас ломается? Получится что у нас сохранился ордер, а продукт отвалися по неизвестной причине, карточный домик посыпался получается?! Или не вижу всей картины?
Есть паттерн типа Unit Of Work, которая оборачивает несколько репозиториев, чтобы сделать коммит, только когда они все завершили операции. Но это не лучшее решение, т.к. UoW живет на уровне сервисов и абстракция хранения данных неявно протекает
@@ДаниилСоловьев-э6ш а какие ещё есть решения? Понимаю, всё зависит от ситуации, но хотелось бы почитать про другие варианты.
@@IvanIvanov-re8bk как вариант не использовать репозитории) для многих микросервисов абсолютно нормально писать код бизнес логики и походов в бд прямо в хэндлере. Пусть будет хэндлер на 50 строчек, это помещается на экран и с этим можно будет в дальнейшем разобраться другому человеку. И транзакции можно будет легко настроить
Чот смешал много в кучу. Сущности как будто частично срастил с vo, dto откуда то - это не вид объекта, а просто назначение некоторых vo. Слои вольно поданы, ну хотя бы есть. Инфра инжектирована прямо в представление (если 500 строк сервис, конечно, чо бы нет). Вобщем вольная трактовка ддд как некоего элемента слоёной архитектуры с намеком на чистую
За видео спасибо. Но вопрос к оператору - а зачем в произвольные моменты переключать вид из камеры? Это же не "Матрица", достаточно простого вида "в анфас".