Всё так. И смотришь на этот "большой красивый мир микросервисов" как через щель в заборе :( С другой стороны - для того мы и развиваемся, чтобы иметь возможность выбирать проекты, на которых нам бы хотелось работать. Правда сейчас ситуация на рынке не фонтан, выбирать не приходится.
Очень круто, спасибо! Пока что это самый лучший урок по DDD из тех, что я видел Очень хотелось бы, что бы ты также упоминул о уровнях DDD и также о других модулях приложения, таких как Service, Factory, Store, Repository и т.д. Но и так в целом у тебя получился весьма весомый и хорошо спроектированный урок Кайф)
Еще: CQRS, UseCase\Interactor, Domain events, domain service, транзакционная цепочка агрегатов, потоки между агрегатами, субдоменами, трилема, признаки чистоты и полноты модели. Вынесение части логики в app, чтобы сохранить чистоту домена и холивар на этот счет. Связь чистой кричащей архитектуры дяди Боба, гексагонал и ДДД. Типичные паттерны в ДДД.
Я так понимаю это уже более продвинутые топики) Можешь поделиться где ты о них читал, а то некоторые термины, по типу транзакционной цепочки агрегатов ни в книге Эванса, ни в интернете не нашел, а любопытно.
@@АлексейЩеблыкин-ь9ы Два типа согласованности: транзакционная согласованность агрегата и итоговая согласованность. Итоговая согласованность может потребовать провести цепь транзакций по нескольким агрегатам. Как я понимаю это, изменение состояния в Счетах по событию Оплата запускает цепь транзакций по другим агрегатам (в другие ограниченные контексты). И тут проблема, как это реализовать (события домена, например, сага..) и как компенсировать в случае сбоев. А сбой может быть технический или же бизнес-процессный, например, доставка с текущего момента не может отвезти 6м стрелу, т.к. автопарк изменился. Но в итоге, каждый агрегат должен сохранить consistency и инвариант.
15:08 интересны связи между BC, есть ли bidirect потоки, насколько высок coupling. Как конкретно реализованы User & Client, если они мапятся в одну сущность БД, например.
26:41 стоит ли делать такой большой Aggregate? Factory для него будет объемный. Этот Aggregate имеет одну транзакционную границу? Бизнес-логика должна быть вшита в Aggregate или injection\delegate и куда? А если бизнес-логика в стиле "не более трех за последний год", то race condition и concurency проблема, транзакция...
17:24 entity Order имеет ambient context из-за времени. Т.е. получается impure. Как передать получение Времени? Как сервис? Как plain value? 20:31 entity Order.client - вопрос, нужна ли сущность клиента? Order не нужно фото клиента, его имя и хобби. Получается, что Client в данном BoundedContext может иметь лишь Id.
Вопрос про VO. В домене используется VO\IdInterface, требующий метод isEqualsTo. В infrastructure есть реализация этого интерфейса, например, UUIDv7. Каждая реализация имеет свой метод isEqualsTo, понятно, что для UUIDv7 и UUIDv4 способы разные. Причем, реализации имеют зависимость от vendor amsey\uuid, который обеспечивает проверку isEqualsTo. Domain model Entity используют VO\IdInterface, куда мапится infrastructure\UUIDv7. Например, SomeRepository->nextID возвращает VO\IdInterface в виде infrastructure\UUIDv7. Вопрос - это норма? Тут видна не-чистота Домена через VO\IdInterface.
Постоянно слежу за вашими выпусками, официально уровень не джун, но, признаюсь, все равно периодически открывается либо то, о чем забыл, либо какие-то нюансы о которых не знал. Смотрю ваши видео на пару с документацией: чуть что сразу лезу в детали. Макс, очень бы хотелось разборы каких-то интересных или может просто распространенных кейсов/задач с использованием тех или иных фреймворков или паттернов проектирования. Разнообразного опыта у вас много, поделитесь практикой)
ДДД - это таки моделирование процессов бизнеса, бизнес-сущности как база. Бизнес платит за приятные Event: order has been paid, State:delivered. Агрегат определяется бизнес-транзакцией, т.е. процессом. BC - на основе ценности, очевидности и потока событий. Цель бизнеса - что-то менять. Цель программы - тоже что-то менять. Поэтому event, state, side-effect выходят на первый план.
На примере разбора ValueObject. Как у нас в базе лежит price? Если оба поля по итогу лежат в order - то зачем ее отделять. Если поля вынесены в отдельную таблицу, то у них появляется Id и они превращаются в Entity. А если они в одной таблице, то мы пишем на Order gerPrice который возвращает новый объект типа price?
Я не спец, но PriceValueObject хранит фракцию и валюту. Тут не может быть идентификатора. Заказ хранит итоговую стоимость как фракция и валюта. В домене есть понятие Price (в виде PriceValueObject), а как оно будет мапиться туда и обратно - дело десятое. Домен не знает, что у вас БД. Ему нужны лишь понятия, заполненные данными. Домен не зависит от инфраструктуры.
Дуже важлива інформація! Було б чудово, якщо б ви ще розглянули забезпечення транзакційності в скоупі декількох мікросервісів. Дуже дякую за вашу працю!
Про то, что мы вынуждены всегда доставать агрегат целиком чтобы изменить одну его запчасть - не правда. Иногда это даже вредно. Мы запросто можем достать одну сущность из всего агрегата, и модифицировать ее. Важно только, чтобы результатом работы не стало нарушение консистентности агрегата. Но работать точечно - можно, и часто - нужно.
Абсолютно непонятно из данного видео как вельюобджекты должны храниться в бд. В виде джейсон в свойстве энтити или как? Айдишника-то нет… но это затруднит бизнесовые выборки типа «список пользователей, заплативших более 10 раз от 100₽ за последние 20 лет»… в чем смысл данного примера?
Дадада...микросервис на базе express задеплоинного монолитом в AWS Lambda (типа для того, чтобы быстро было и по минималке использовать нативный API Gateway....а по факту потому что в команде нет человека с соответсвующей квалификацией )
Макс, что думаешь о таком подходе к собеседованиям? ua-cam.com/video/SMYs5CKCk9M/v-deo.html Мне кажется интересный подход, может проведешь собес в таком стиле?)
Посмотрел))) Ничего интересного не нашел. Если честно. Ощущение, что просто хайпанули на интересной теме. Идея обновленных подоходны к интервью классная, но как-то неконструктивно получилось. Потому я Евгению не верю 🤨 Ощущение, что под копирку рассказывает, а не то что в ИТ сегодня происходит. А так, это его субъективное мнение. В итоге рынок показывает, что работает, а что нет. Легко сказать: «Весь мир не используется мою крутую идею». Абсолютно другое дело, донести свою мысль в мир и сделать ее живой. Ну а другое, не стоит путать попытку найти фундаментального инженера с некомпетентностью некоторых случаев. Далеко не всегда интервью сливается в холодную теорию. Все зависит от ситуации. Как-то так 🤓
Макс, привет. Спасибо за твои видео. Трудно спорить с тем, что написано на заставке. Но на заднем фоне у тебя солдат НАТО (ошибаюсь?). Именно они бомбили столицу Югославии, + Ирак, Ливия и тд. Это сочетание текста и картинки вызвало сильное возмущение. Не мог бы пояснить, считаешь ли ты агрессией те войны, о которых я упомянул и как картинка соотносится с текстом заставки?
Было бы неплохо, вместо прекраснейшего лица больше визуализаций, как у Дениса Казанцева. А так получилось ППР. Спору нет, объяснение грамотное, но ППР. Посидели, попиздели, разошлись
Столько принципов, а по итогу работаешь с Легаси кодом в монолите, с постоянными самоповторами 🫠
🤣 жЫза
Всё так. И смотришь на этот "большой красивый мир микросервисов" как через щель в заборе :(
С другой стороны - для того мы и развиваемся, чтобы иметь возможность выбирать проекты, на которых нам бы хотелось работать. Правда сейчас ситуация на рынке не фонтан, выбирать не приходится.
@@khvastov.maksym я вот, сижу выбираю и норм)
@@xmahz Я тоже выбираю, и даже по собесам хожу, но команды сейчас балованые, имхо)
@@khvastov.maksym Они всегда такие мне кажется)
Спасибо за замечательный контент! У меня 4 года опыта и почти каждое собеседование начинается с вопросов архитектуры :) очень полезное видео
Смотрел доклад какого то типа, ничего не понял.
У тебя очень доступно вышло объяснить.
Спасибо
Очень круто, спасибо! Пока что это самый лучший урок по DDD из тех, что я видел
Очень хотелось бы, что бы ты также упоминул о уровнях DDD и также о других модулях приложения, таких как Service, Factory, Store, Repository и т.д.
Но и так в целом у тебя получился весьма весомый и хорошо спроектированный урок
Кайф)
Огонь, спасибо.
Очень клёво, конечно каждый разработчик должен знать.
Еще: CQRS, UseCase\Interactor, Domain events, domain service, транзакционная цепочка агрегатов, потоки между агрегатами, субдоменами, трилема, признаки чистоты и полноты модели. Вынесение части логики в app, чтобы сохранить чистоту домена и холивар на этот счет. Связь чистой кричащей архитектуры дяди Боба, гексагонал и ДДД. Типичные паттерны в ДДД.
Я так понимаю это уже более продвинутые топики) Можешь поделиться где ты о них читал, а то некоторые термины, по типу транзакционной цепочки агрегатов ни в книге Эванса, ни в интернете не нашел, а любопытно.
@@АлексейЩеблыкин-ь9ы Два типа согласованности: транзакционная согласованность агрегата и итоговая согласованность. Итоговая согласованность может потребовать провести цепь транзакций по нескольким агрегатам. Как я понимаю это, изменение состояния в Счетах по событию Оплата запускает цепь транзакций по другим агрегатам (в другие ограниченные контексты). И тут проблема, как это реализовать (события домена, например, сага..) и как компенсировать в случае сбоев. А сбой может быть технический или же бизнес-процессный, например, доставка с текущего момента не может отвезти 6м стрелу, т.к. автопарк изменился. Но в итоге, каждый агрегат должен сохранить consistency и инвариант.
15:08 интересны связи между BC, есть ли bidirect потоки, насколько высок coupling. Как конкретно реализованы User & Client, если они мапятся в одну сущность БД, например.
26:41 стоит ли делать такой большой Aggregate? Factory для него будет объемный. Этот Aggregate имеет одну транзакционную границу? Бизнес-логика должна быть вшита в Aggregate или injection\delegate и куда? А если бизнес-логика в стиле "не более трех за последний год", то race condition и concurency проблема, транзакция...
17:24 entity Order имеет ambient context из-за времени. Т.е. получается impure. Как передать получение Времени? Как сервис? Как plain value?
20:31 entity Order.client - вопрос, нужна ли сущность клиента? Order не нужно фото клиента, его имя и хобби. Получается, что Client в данном BoundedContext может иметь лишь Id.
Вопрос про VO. В домене используется VO\IdInterface, требующий метод isEqualsTo. В infrastructure есть реализация этого интерфейса, например, UUIDv7. Каждая реализация имеет свой метод isEqualsTo, понятно, что для UUIDv7 и UUIDv4 способы разные. Причем, реализации имеют зависимость от vendor
amsey\uuid, который обеспечивает проверку isEqualsTo. Domain model Entity используют VO\IdInterface, куда мапится infrastructure\UUIDv7. Например, SomeRepository->nextID возвращает VO\IdInterface в виде infrastructure\UUIDv7. Вопрос - это норма? Тут видна не-чистота Домена через VO\IdInterface.
Постоянно слежу за вашими выпусками, официально уровень не джун, но, признаюсь, все равно периодически открывается либо то, о чем забыл, либо какие-то нюансы о которых не знал. Смотрю ваши видео на пару с документацией: чуть что сразу лезу в детали.
Макс, очень бы хотелось разборы каких-то интересных или может просто распространенных кейсов/задач с использованием тех или иных фреймворков или паттернов проектирования. Разнообразного опыта у вас много, поделитесь практикой)
Вот уже начали пробовать делать видео с разбором задач с собеседований))
Как раз должно быть следующее на подобную тематику
Видео очень полезное)) Лучше чем куча бесполезных статей в интернете)
Понравилась подача, подписался, лайк
ДДД - это таки моделирование процессов бизнеса, бизнес-сущности как база. Бизнес платит за приятные Event: order has been paid, State:delivered. Агрегат определяется бизнес-транзакцией, т.е. процессом. BC - на основе ценности, очевидности и потока событий. Цель бизнеса - что-то менять. Цель программы - тоже что-то менять. Поэтому event, state, side-effect выходят на первый план.
Немного разбираюсь в DDD, могу сказать, что у ведущего приятная речь, но объясняет на четверочку.
Большое спасибо!
На примере разбора ValueObject. Как у нас в базе лежит price? Если оба поля по итогу лежат в order - то зачем ее отделять. Если поля вынесены в отдельную таблицу, то у них появляется Id и они превращаются в Entity. А если они в одной таблице, то мы пишем на Order gerPrice который возвращает новый объект типа price?
Я не спец, но PriceValueObject хранит фракцию и валюту. Тут не может быть идентификатора. Заказ хранит итоговую стоимость как фракция и валюта. В домене есть понятие Price (в виде PriceValueObject), а как оно будет мапиться туда и обратно - дело десятое. Домен не знает, что у вас БД. Ему нужны лишь понятия, заполненные данными. Домен не зависит от инфраструктуры.
Для понимания вашего примера - это может быть массив или иная структура в таблице order
Отличное видео и канал. Спасибо!
Привет, спасибо за такой информативный видос :) Скажи пожалуйста, ты когда ходил по собесам, тебя спрашивали такие заезженные вопросы про Java core?
Привет ))
Ох, чего только не спрашивают. Бывают крутые собеседования, а бывают скучные и бессмысленные
Дуже важлива інформація! Було б чудово, якщо б ви ще розглянули забезпечення транзакційності в скоупі декількох мікросервісів. Дуже дякую за вашу працю!
Гарна пропозиція. Записав в пул тем для відео. Респект 👍
смотря какой driven, смотря какой design
Про то, что мы вынуждены всегда доставать агрегат целиком чтобы изменить одну его запчасть - не правда. Иногда это даже вредно. Мы запросто можем достать одну сущность из всего агрегата, и модифицировать ее. Важно только, чтобы результатом работы не стало нарушение консистентности агрегата. Но работать точечно - можно, и часто - нужно.
в принципе это такой фильтр, как и СОЛИД например, очень хорошо и понятно рассказал.
Абсолютно непонятно из данного видео как вельюобджекты должны храниться в бд. В виде джейсон в свойстве энтити или как? Айдишника-то нет… но это затруднит бизнесовые выборки типа «список пользователей, заплативших более 10 раз от 100₽ за последние 20 лет»… в чем смысл данного примера?
Спасибо!)
DDD уже на джуна спрашивают?) Видео пока не смотрел, тема определенно, интересная и важная.
Это бесполезно, джун тебе не назовет зачем нужен DDD, только если не заучит теорию)
На джуна конечно же нет.
Но сам понимаешь, все зависит от собеседующего и его желаний.
Как по мне, DDD для middle+
Дадада...микросервис на базе express задеплоинного монолитом в AWS Lambda (типа для того, чтобы быстро было и по минималке использовать нативный API Gateway....а по факту потому что в команде нет человека с соответсвующей квалификацией )
16:50 - всё видео звучит очень абстрактно
thanks
чем больше узнаю о ддд, тем больше понимаю, что эта муть нафиг не нужна
Макс, что думаешь о таком подходе к собеседованиям?
ua-cam.com/video/SMYs5CKCk9M/v-deo.html
Мне кажется интересный подход, может проведешь собес в таком стиле?)
Посмотрел)))
Ничего интересного не нашел. Если честно. Ощущение, что просто хайпанули на интересной теме.
Идея обновленных подоходны к интервью классная, но как-то неконструктивно получилось.
Потому я Евгению не верю 🤨
Ощущение, что под копирку рассказывает, а не то что в ИТ сегодня происходит.
А так, это его субъективное мнение. В итоге рынок показывает, что работает, а что нет. Легко сказать: «Весь мир не используется мою крутую идею». Абсолютно другое дело, донести свою мысль в мир и сделать ее живой.
Ну а другое, не стоит путать попытку найти фундаментального инженера с некомпетентностью некоторых случаев. Далеко не всегда интервью сливается в холодную теорию. Все зависит от ситуации.
Как-то так 🤓
@@maksdobrynin истина где то рядом)
хм... про язык написания техзаданий... чтобы заказчики тоже шевелили извилинами и не перекладывали это на программистов
а что делать когда заказчик и есть программист, но извилины не извилятся? ))))
З.Ы. Риторический вопрос
Макс, привет. Спасибо за твои видео.
Трудно спорить с тем, что написано на заставке. Но на заднем фоне у тебя солдат НАТО (ошибаюсь?). Именно они бомбили столицу Югославии, + Ирак, Ливия и тд. Это сочетание текста и картинки вызвало сильное возмущение. Не мог бы пояснить, считаешь ли ты агрессией те войны, о которых я упомянул и как картинка соотносится с текстом заставки?
Картинка на доске огонь))💪
он еще вспомнит про эту картиночку
Ну очень много лишнего текста.
Этот аспект вообще плохо понимаем всеми.
Из-за этого холивары и "мой ДДД лучше твоего". Чем выше абстракция, тем больше вариантов реализации.
Можно было гораздо короче
Было бы неплохо, вместо прекраснейшего лица больше визуализаций, как у Дениса Казанцева. А так получилось ППР. Спору нет, объяснение грамотное, но ППР. Посидели, попиздели, разошлись
Спасибі очень полезно и спасибо за поддержку💛💙
Э