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