Очень толковый доклад! Всё чётко и по делу, даже вопросы были в тему (на 4)! Отдельное спасибо за примеры кода - их обычно особенно не хватает. Буду рекомендовать всем как вводную по DDD.
Спасибо :) Это было не волнение, просто я накануне полностью потерял голос, а всю ночь перед докладом пролежал с температурой и жутким орви. Поэтому весь день до доклада сидел в номере и молчал, чтобы голоса хватило на доклад и его хватило, почти ))
Очень круто дополняет лекцию th-cam.com/video/JOy_SNK3qj4/w-d-xo.html. В ней было рассказано про трилемму ДДД, а в этой красивое решение этой трилеммы через Separate Interface.
Мне понравилось, спасибо) была оговорка или такой прикол: чистый код Боба Мартина. Он же Роберт. Но я подумал может на западе все Бобы, типо как Дядюшка Сэм😅
Первый пример вызывал вопросы: у нас ведь пользователь по описанию получает скидку, в задаче (вики) никакого скидочного калькулятора не существует; второй момент который не понятен - в калькулятор инжектится репозиторий заказов и он же инжектится в сервис, а потом транзитивно через калькулятор - это нормально? В общем, если в первом примере просто переписать расчёт скидки или вынести в отдельный метод, то, как мне кажется, будет не хуже.
Отдельный класс Calculator нужен для соблюдения SRP. В "алгоритм" чекаута скидка входит в виде "применяем скидку". Детали расчета скидки - это другой уровень абстракции. Кроме того, так будет проще тестировать: мухи - отдельно, котлеты - отдельно. С репозиторием в данном случае проблем нет, но в принципе можно калькулятор не инжектить, а сконструировать вручную через new DiscountCalculator. Если забить на SRP, то да, можно сделать расчет скидки методом внутри CheckoutService, всё зависит от планов на дальнейшую разработку и понимания того, как будут развиваться бизнес-требования.
Будет хуже, Сделайте его Public? Он же не должен использоваться вне сервиса. Ок private? - Удачи в Unit Testing-е. А если помимо калькулятора ещё десятка методов туда присобачить? Придётся покупать мышку с Infinite Scroll. А если из-за бага вручную напишете консольку чтобы ретроспективно исправить скидику в БД - копи паст?
Почему везде все всю и кругом кричат про принципы ООП и хвастаются своим знанием IoC, а на деле постоянно пытаются познать мир через частное, объяснить общее на частных примерах o_0
скрипт загонит данные... в ДДД - это табу. данные меняются только через агрегаты, иначе во всей этой истории нет никакого смысла. куча абстракций ради абстракций. а потом внешний скрипт жух и все сломал и концов не найти. слабоватое изложение. путанное какое-то и безсистемное.
В том-то и дело, что абстракции ради абстракций не нужны. Если скрипта достаточно, чтобы выразить бизнес-логику - прекрасно! Только напиши этот скрипт человеческим языком, используя ubiquitous language.
@@alexeymerson и соблюдая все инварианты из моделей? сделать то можно, а тесты? А если база на продакшене? Очень это рисковый вариант. А если еще и в пятницу такое задеплоить или перед отпуском - совсем замечательный выговор будет от руководства, на матерном ubiquitous language. Возможно я что-то не понял, но речь шла об изменении данных в бд мимо домен слоя. Я высказал свое несогласие править SQL скриптами данные в базе, которые записаны моделями.
@@alexeymerson будет мне наука, нужно тегать по времени, куда коммент отписал, возможно где-то в самом докладе еще было, но я сейчас только в ответе на вопрос нашел явный прагматичный совет загнать данные хоть и разово скриптом th-cam.com/video/CR9mLGN9jh0/w-d-xo.html вот тут я не согласен, можно данные балком брать и грузить через команды CQS или UseCases, написав шелл команду для этого, чтобы данные гарантировано прошли через все проверки и валидации. Возможно где-то в докладе еще было, я сейчас ленюсь смотреть его внимательно целиком. Вообще-то может я и погорячился, в докладе есть много полезного для старта в этой теме, я его смотрел два раза, бомбануло во второй, когда я уже насмотрелся всякого, например Хорикова и его доклад про валидацию данных.
@@odys-wise спасибо) Тут вопрос из зала по сути был про то, что реализация подходов ДДД обычно тяжеловесная и не подходит для хайлоад. И в целом мой ответ за 5 лет не изменился: надо либо признать, что ваш домен высоконагруженный и нужно ослаблять контроль консистентности (а обычно тяжеловесность вызвана именно жесткими правилами валидации), либо ситуация с высокой нагрузкой исключительная и нужно подпереть ее костылем - сделать возможность bulk-операции, но возложить ответственность за валидность данных на оператора например. Т.к. вопрос был достаточно абстрактный, то и ответить более конкретно на него нельзя без деталей.
Лайк за правильное произношение английских слов :) Это одна из причин, по которой я обычно избегаю просмотр каких-либо видеороликов по программированию на русском (неправильное произношение).
Отличный доклад от Егора Летова, очень доходчиво.
Говорят, он еще песни поет.
За вступление точно зачёт!!!
Смотрю дальше.
несколько миллионов лет рефакторинг! Докладчик, видимо, на стэндап вышел ;)
Лучшее и компактное объяснение проблемы ddd
Очень толковый доклад! Всё чётко и по делу, даже вопросы были в тему (на 4)! Отдельное спасибо за примеры кода - их обычно особенно не хватает. Буду рекомендовать всем как вводную по DDD.
Думал ща ОООО Моя оборона будет петь...)) Хороший доклад.
Крутой доклад! Спасибо!
Что не так с тумбочкой под ноутом? Почему она перемещается?
Спасибо, без лишних усложнений!
дал объяснения многим возникшим вопросам. Спасибо!
Отличный доклад! Многое стало понятнее))
Прекрасный доклад! Особенно для цели погружения в DDD.
Классный доклад. У меня всю дорогу был вопрос о Clean Architecture. Хорошо, что в конце спросили))
Ссылки из презентации собрал тут: telegra.ph/Aleksej-Merson--Domain-driven-design-recept-dlya-pragmatika-Ssylki-03-17
Доменный мир победил. Архитектура как у людей
1С - DDD который мы заслужили
Хорошо подготовился, с юмором. Даже волнение не мешает слушать :)
Спасибо :) Это было не волнение, просто я накануне полностью потерял голос, а всю ночь перед докладом пролежал с температурой и жутким орви. Поэтому весь день до доклада сидел в номере и молчал, чтобы голоса хватило на доклад и его хватило, почти ))
Это топ. Егор Летов рассказывает про DDD. Материал качественный.
Интересный доклад, спасибо.
О#@еннейший доклад, спасибо!
респектую докладчику... очень доступно и по полочкам...PS, никогда не приходило даже в голову использовать русский язык в названиях на шарпе)))
Крутой доклад!
Хорошее изложение, спасибо
Отличный доклад
Spasibo. Otlichnij doklad. Smotrju v mesto Netflixa. :)
malacis ;)
Каков правильный порядок чтения глав голубой книги Эванса?
Спасибо за доклад!
PS: Ребят вы обычно реализуете свой слой репозитория или просто используете EF?)
EF. Не вижу смысла создавать дополнительный слой репозитория если EF и так его реализует.
Также, юзаю только Ef
ссылки из доклада вынести в описание зло?
14:57 как он смог поймать стакан на бегающей туда-сюда тумбочке?
Смотреть на скорости х1.25
1.75
2.0
@@MrAmmid 0.25
07:53 Ключевые идеи стратегического планирования
Thx!
Очень круто дополняет лекцию th-cam.com/video/JOy_SNK3qj4/w-d-xo.html. В ней было рассказано про трилемму ДДД, а в этой красивое решение этой трилеммы через Separate Interface.
от движения камеры сейчас меня укачает..
Почему тумбочка двигается все время?
Встроенный гироскоп не откалибровали
@@ababush вы уж пожалуйста, откалибруйте!))
Мне понравилось, спасибо) была оговорка или такой прикол: чистый код Боба Мартина. Он же Роберт. Но я подумал может на западе все Бобы, типо как Дядюшка Сэм😅
Боб - это сокращение от Роберта.
Так же как у нас Саша - Александр.
У Роберта Мартина погонялово Дядя Боб
А, действительно) Спасибо @@learning867
Оооо-ооо моя архитектура
1.5х минимум.
ibicheskiy language
Арамис уже не тот
Первый пример вызывал вопросы: у нас ведь пользователь по описанию получает скидку, в задаче (вики) никакого скидочного калькулятора не существует; второй момент который не понятен - в калькулятор инжектится репозиторий заказов и он же инжектится в сервис, а потом транзитивно через калькулятор - это нормально? В общем, если в первом примере просто переписать расчёт скидки или вынести в отдельный метод, то, как мне кажется, будет не хуже.
Отдельный класс Calculator нужен для соблюдения SRP. В "алгоритм" чекаута скидка входит в виде "применяем скидку". Детали расчета скидки - это другой уровень абстракции. Кроме того, так будет проще тестировать: мухи - отдельно, котлеты - отдельно. С репозиторием в данном случае проблем нет, но в принципе можно калькулятор не инжектить, а сконструировать вручную через new DiscountCalculator. Если забить на SRP, то да, можно сделать расчет скидки методом внутри CheckoutService, всё зависит от планов на дальнейшую разработку и понимания того, как будут развиваться бизнес-требования.
Будет хуже, Сделайте его Public? Он же не должен использоваться вне сервиса. Ок private? - Удачи в Unit Testing-е. А если помимо калькулятора ещё десятка методов туда присобачить? Придётся покупать мышку с Infinite Scroll. А если из-за бага вручную напишете консольку чтобы ретроспективно исправить скидику в БД - копи паст?
Почему везде все всю и кругом кричат про принципы ООП и хвастаются своим знанием IoC, а на деле постоянно пытаются познать мир через частное, объяснить общее на частных примерах o_0
к сожалению, вода водой. как по мне, давным-давно известные приемы, техники и принципы типа SOLID пытаются подавать под новым соусом.
На скорости 1,5 - норм
скрипт загонит данные... в ДДД - это табу. данные меняются только через агрегаты, иначе во всей этой истории нет никакого смысла. куча абстракций ради абстракций. а потом внешний скрипт жух и все сломал и концов не найти. слабоватое изложение. путанное какое-то и безсистемное.
В том-то и дело, что абстракции ради абстракций не нужны. Если скрипта достаточно, чтобы выразить бизнес-логику - прекрасно! Только напиши этот скрипт человеческим языком, используя ubiquitous language.
@@alexeymerson и соблюдая все инварианты из моделей? сделать то можно, а тесты? А если база на продакшене? Очень это рисковый вариант. А если еще и в пятницу такое задеплоить или перед отпуском - совсем замечательный выговор будет от руководства, на матерном ubiquitous language. Возможно я что-то не понял, но речь шла об изменении данных в бд мимо домен слоя. Я высказал свое несогласие править SQL скриптами данные в базе, которые записаны моделями.
@@odys-wise а можешь написать тайм-код, где говорится про скрипт? Я может тоже тебя неправильно понял
@@alexeymerson будет мне наука, нужно тегать по времени, куда коммент отписал, возможно где-то в самом докладе еще было, но я сейчас только в ответе на вопрос нашел явный прагматичный совет загнать данные хоть и разово скриптом
th-cam.com/video/CR9mLGN9jh0/w-d-xo.html
вот тут я не согласен, можно данные балком брать и грузить через команды CQS или UseCases, написав шелл команду для этого, чтобы данные гарантировано прошли через все проверки и валидации. Возможно где-то в докладе еще было, я сейчас ленюсь смотреть его внимательно целиком. Вообще-то может я и погорячился, в докладе есть много полезного для старта в этой теме, я его смотрел два раза, бомбануло во второй, когда я уже насмотрелся всякого, например Хорикова и его доклад про валидацию данных.
@@odys-wise спасибо) Тут вопрос из зала по сути был про то, что реализация подходов ДДД обычно тяжеловесная и не подходит для хайлоад. И в целом мой ответ за 5 лет не изменился: надо либо признать, что ваш домен высоконагруженный и нужно ослаблять контроль консистентности (а обычно тяжеловесность вызвана именно жесткими правилами валидации), либо ситуация с высокой нагрузкой исключительная и нужно подпереть ее костылем - сделать возможность bulk-операции, но возложить ответственность за валидность данных на оператора например. Т.к. вопрос был достаточно абстрактный, то и ответить более конкретно на него нельзя без деталей.
Как-то ответы на вопросы после доклада были невпопад мне кажется, возможно спикер волновался :) А так доклад крутой, стоит смотреть!
Лайк за правильное произношение английских слов :) Это одна из причин, по которой я обычно избегаю просмотр каких-либо видеороликов по программированию на русском (неправильное произношение).
да вы, батенька, зануда ))
Rebelовцы, а ну-ка смотреть всем!!!
Ниочем. У докладчика очень слабые знания DDD.
Код на русском это печаль - выглядит отстойно и может использоваться в локальных и колхозных проектах.
Абсолютно согласен!
Можете дать ссылку на более сильных докладчиков? Здесь и правда никакой глубины понимания DDD я у оратора не заметил.
Хейтить всегда легче
С нетерпением ждём свое, по всей видимости идеальное и полное понимание ddd от автора коммента, хотя бы текстом.
дичь