Алексей Мерсон - Domain-driven design: рецепт для прагматика
Ғылым және технология
Ближайшая конференция - DotNext 2024, 10 - 11 сентября, Москва + online
Подробности и билеты: jrg.su/x2GKnA
- -
Богатый личный опыт позволяет рассказывать Алексею сложные вещи простым и понятным языком.
Domain-driven design - набор подходов к разработке, который, с одной стороны, на слуху, а с другой, к нему очень сложно подступиться. Есть большие книги (Эванс, Вернон), но далеко не все читают их и еще меньше читают их до конца. А даже и дочитав, могут упустить суть за обилием деталей. Сотни статей в блогах и постов на StackExchange только усугубляют эту проблему.
- О чем жалеет Эванс спустя 15 лет после выхода его книги?
- Bounded context: имеет ли значение размер?
- Все ли паттерны одинаково полезны?
- И, наконец, в чем же суть domain-driven design?
Обо всём этом расскажет Алексей в своем докладе. Кто не знает - узнает. Кто знает - узнает лучше.
Пікірлер: 89
Отличный доклад от Егора Летова, очень доходчиво.
Думал ща ОООО Моя оборона будет петь...)) Хороший доклад.
За вступление точно зачёт!!! Смотрю дальше.
@alexanderk3762
3 жыл бұрын
несколько миллионов лет рефакторинг! Докладчик, видимо, на стэндап вышел ;)
Спасибо, без лишних усложнений!
Крутой доклад! Спасибо!
Лучшее и компактное объяснение проблемы ddd
Очень толковый доклад! Всё чётко и по делу, даже вопросы были в тему (на 4)! Отдельное спасибо за примеры кода - их обычно особенно не хватает. Буду рекомендовать всем как вводную по DDD.
Хорошо подготовился, с юмором. Даже волнение не мешает слушать :)
дал объяснения многим возникшим вопросам. Спасибо!
Доменный мир победил. Архитектура как у людей
Хорошее изложение, спасибо
1С - DDD который мы заслужили
Крутой доклад!
Ссылки из презентации собрал тут: telegra.ph/Aleksej-Merson--Domain-driven-design-recept-dlya-pragmatika-Ssylki-03-17
Это топ. Егор Летов рассказывает про DDD. Материал качественный.
Что не так с тумбочкой под ноутом? Почему она перемещается?
Отличный доклад
О#@еннейший доклад, спасибо!
Thx!
Прекрасный доклад! Особенно для цели погружения в DDD.
респектую докладчику... очень доступно и по полочкам...PS, никогда не приходило даже в голову использовать русский язык в названиях на шарпе)))
Каков правильный порядок чтения глав голубой книги Эванса?
14:57 как он смог поймать стакан на бегающей туда-сюда тумбочке?
Очень круто дополняет лекцию kzread.info/dash/bejne/fIOtwbWHe5bXmpc.html. В ней было рассказано про трилемму ДДД, а в этой красивое решение этой трилеммы через Separate Interface.
от движения камеры сейчас меня укачает..
Оооо-ооо моя архитектура
Мне понравилось, спасибо) была оговорка или такой прикол: чистый код Боба Мартина. Он же Роберт. Но я подумал может на западе все Бобы, типо как Дядюшка Сэм😅
@learning867
Жыл бұрын
Боб - это сокращение от Роберта. Так же как у нас Саша - Александр.
@evgeniizaets9243
10 ай бұрын
У Роберта Мартина погонялово Дядя Боб
@user-hl7lr7wo6m
5 ай бұрын
А, действительно) Спасибо @@learning867
07:53 Ключевые идеи стратегического планирования
1.5х минимум.
Почему тумбочка двигается все время?
@ababush
2 жыл бұрын
Встроенный гироскоп не откалибровали
@eabrega
2 жыл бұрын
@@ababush вы уж пожалуйста, откалибруйте!))
На скорости 1,5 - норм
Почему везде все всю и кругом кричат про принципы ООП и хвастаются своим знанием IoC, а на деле постоянно пытаются познать мир через частное, объяснить общее на частных примерах o_0
к сожалению, вода водой. как по мне, давным-давно известные приемы, техники и принципы типа SOLID пытаются подавать под новым соусом.
Rebelовцы, а ну-ка смотреть всем!!!
скрипт загонит данные... в ДДД - это табу. данные меняются только через агрегаты, иначе во всей этой истории нет никакого смысла. куча абстракций ради абстракций. а потом внешний скрипт жух и все сломал и концов не найти. слабоватое изложение. путанное какое-то и безсистемное.
@alexeymerson
10 ай бұрын
В том-то и дело, что абстракции ради абстракций не нужны. Если скрипта достаточно, чтобы выразить бизнес-логику - прекрасно! Только напиши этот скрипт человеческим языком, используя ubiquitous language.
@odys-wise
10 ай бұрын
@@alexeymerson и соблюдая все инварианты из моделей? сделать то можно, а тесты? А если база на продакшене? Очень это рисковый вариант. А если еще и в пятницу такое задеплоить или перед отпуском - совсем замечательный выговор будет от руководства, на матерном ubiquitous language. Возможно я что-то не понял, но речь шла об изменении данных в бд мимо домен слоя. Я высказал свое несогласие править SQL скриптами данные в базе, которые записаны моделями.
@alexeymerson
10 ай бұрын
@@odys-wise а можешь написать тайм-код, где говорится про скрипт? Я может тоже тебя неправильно понял
@odys-wise
10 ай бұрын
@@alexeymerson будет мне наука, нужно тегать по времени, куда коммент отписал, возможно где-то в самом докладе еще было, но я сейчас только в ответе на вопрос нашел явный прагматичный совет загнать данные хоть и разово скриптом kzread.info/dash/bejne/dYZtz66AfpzQmJM.html вот тут я не согласен, можно данные балком брать и грузить через команды CQS или UseCases, написав шелл команду для этого, чтобы данные гарантировано прошли через все проверки и валидации. Возможно где-то в докладе еще было, я сейчас ленюсь смотреть его внимательно целиком. Вообще-то может я и погорячился, в докладе есть много полезного для старта в этой теме, я его смотрел два раза, бомбануло во второй, когда я уже насмотрелся всякого, например Хорикова и его доклад про валидацию данных.
@alexeymerson
10 ай бұрын
@@odys-wise спасибо) Тут вопрос из зала по сути был про то, что реализация подходов ДДД обычно тяжеловесная и не подходит для хайлоад. И в целом мой ответ за 5 лет не изменился: надо либо признать, что ваш домен высоконагруженный и нужно ослаблять контроль консистентности (а обычно тяжеловесность вызвана именно жесткими правилами валидации), либо ситуация с высокой нагрузкой исключительная и нужно подпереть ее костылем - сделать возможность bulk-операции, но возложить ответственность за валидность данных на оператора например. Т.к. вопрос был достаточно абстрактный, то и ответить более конкретно на него нельзя без деталей.
Ниочем. У докладчика очень слабые знания DDD. Код на русском это печаль - выглядит отстойно и может использоваться в локальных и колхозных проектах.
@alexeymerson
3 жыл бұрын
Абсолютно согласен!
@pupazzamobila1006
3 жыл бұрын
Можете дать ссылку на более сильных докладчиков? Здесь и правда никакой глубины понимания DDD я у оратора не заметил.
@ababush
2 жыл бұрын
Хейтить всегда легче
@smartphone6498
9 ай бұрын
С нетерпением ждём свое, по всей видимости идеальное и полное понимание ddd от автора коммента, хотя бы текстом.
дичь
Отличный доклад! Многое стало понятнее))
Интересный доклад, спасибо.
Классный доклад. У меня всю дорогу был вопрос о Clean Architecture. Хорошо, что в конце спросили))
Спасибо за доклад! PS: Ребят вы обычно реализуете свой слой репозитория или просто используете EF?)
@webhunterok
4 жыл бұрын
EF. Не вижу смысла создавать дополнительный слой репозитория если EF и так его реализует.
@artemadeev7444
Жыл бұрын
Также, юзаю только Ef
Смотреть на скорости х1.25
@SeregaPositive
4 жыл бұрын
1.75
@MrAmmid
4 жыл бұрын
2.0
@sh_zik
3 жыл бұрын
@@MrAmmid 0.25
Spasibo. Otlichnij doklad. Smotrju v mesto Netflixa. :)
@denis_penis
4 жыл бұрын
malacis ;)
ссылки из доклада вынести в описание зло?
Первый пример вызывал вопросы: у нас ведь пользователь по описанию получает скидку, в задаче (вики) никакого скидочного калькулятора не существует; второй момент который не понятен - в калькулятор инжектится репозиторий заказов и он же инжектится в сервис, а потом транзитивно через калькулятор - это нормально? В общем, если в первом примере просто переписать расчёт скидки или вынести в отдельный метод, то, как мне кажется, будет не хуже.
@alexeymerson
5 жыл бұрын
Отдельный класс Calculator нужен для соблюдения SRP. В "алгоритм" чекаута скидка входит в виде "применяем скидку". Детали расчета скидки - это другой уровень абстракции. Кроме того, так будет проще тестировать: мухи - отдельно, котлеты - отдельно. С репозиторием в данном случае проблем нет, но в принципе можно калькулятор не инжектить, а сконструировать вручную через new DiscountCalculator. Если забить на SRP, то да, можно сделать расчет скидки методом внутри CheckoutService, всё зависит от планов на дальнейшую разработку и понимания того, как будут развиваться бизнес-требования.
@chrise202
4 жыл бұрын
Будет хуже, Сделайте его Public? Он же не должен использоваться вне сервиса. Ок private? - Удачи в Unit Testing-е. А если помимо калькулятора ещё десятка методов туда присобачить? Придётся покупать мышку с Infinite Scroll. А если из-за бага вручную напишете консольку чтобы ретроспективно исправить скидику в БД - копи паст?
Арамис уже не тот
ibicheskiy language
Как-то ответы на вопросы после доклада были невпопад мне кажется, возможно спикер волновался :) А так доклад крутой, стоит смотреть!
Лайк за правильное произношение английских слов :) Это одна из причин, по которой я обычно избегаю просмотр каких-либо видеороликов по программированию на русском (неправильное произношение).
@sergegindin1658
2 жыл бұрын
да вы, батенька, зануда ))