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