Я поставил лайк за смелость. Доклад мне показался интересным в плане эксперимента. Эдакий живой диалог. Тут нужна подготовленная публика (возможно, на это был расчет), да и докладчик должен быть с погонами и увешан орденами боевых действий. Но получилось так, будт-то чувак бросился в ров с полу-сытыми львами и пытается отбиваться от взмахов их лап, отделался царапинами. Очень напряженная картина, я переживал. Но докладчику я желаю не опускать руки, учиться на ошибках.
Послушал еще раз. Докладчик в 10 минут рассказал основы 3d и все сказал верно в общем-то. И акцент все же на вопросах - т.е. задача была навести актуальный порядок в понимании темы у слушателей. Публика молодцом - задавали хорошие вопросы. Дмитрий молодец - кратко и по делу... Интересно - какая обстановка сейчас с внедрением 3д в "новом" проекте?
Докладчик перепутал определения сабдоменов и ограниченных контекстов. В красной книге Вона Вернона (на которую докладчик ссылался в начале) ясно написано, что сабдомены (подобласти) являются областью ЗАДАЧ, то есть то, что хочет сделать бизнес. Ограниченные контексты представляют собой область РЕШЕНИЙ, куда входит МОДЕЛЬ ПРЕДМЕТНОЙ ОБЛАСТИ (а точнее модель подобласти, если контекст входит в эту подобласть, см рисунок на слайде), и все что определяется моделью - сервисы приложения, отображение(UI) и так далее.
Послушал 10 раз, но так и не понял разницу между subdomain и bounded context... Первое это "программное выражение бизнес ценностей" А второе - "бизнес функционал, описанный аналитиками"
Как-то не серьёзно. Тема обширная, громкое название, а внутри доклад на 10 минут и на два с половиной так себе слайда. Наверное, рассказчик не успел нормально подготовиться.
называется не разобрался в DDD - а уже на конференцию приехал и начал всем доносить что DDD не торт. скоро надо будет вводить модерацию вот таких вот "спецов" - чтобы не позорились.
@@IliaGlazkov можно было упомянуть, что сам Эванс приводит, что внедрение всех принципов или большинства аспектов изложенных им (считать DDD), увеличивает трудозатраты в разы. Эванс говорит, что допускается использовать в DDD подобных системах срезы в виде используемых фреймворков для сокращения трудозатрат на разработку. Это тонкая грань без формализованных критериев когда нужно в DDD и когда не нужно в DDD. Хотелось бы, судя по 11 минутам доклада, чтобы его автор привел критерии или примеры избыточности DDD, если мы говорим о цели доклада. Нельзя сказать тезис без доказательства людям, которые тезис считают ложным. Тогда не придется оспаривать сам тезис, а придется обсуждать (не)состоятельность аргументов. Как можно доказать, что DDD не работает. Можно начать с утверждения, что DDD - это идеал системы, к которой можно стремиться, но он не достижим по ряду объективных причин (критериев). Критерий первый - трудозатраты и срочность разработки. Можно провести эксперимент, где две команды разработчиков с одинаковой квалификацией пишут одну и туже задачу в сжатые сроки. Разница между ними, что одна команда пишет все по заветам DDD, а другая не обязана им следовать. Затем экспертная комиссия может оценить работы участников на читаемость, поддерживаемость, производительность, подставьте нужное. Можно подойти с другой стороны и заявить, что DDD из-за своей неформальности является философской идеей и не может быть формально описано. А раз неформальное, то не может быть достигнуто. Разработчики будут вечно недовольные, другие разработчики будут спорить что у них DDD, а у вас не DDD, и так далее... Проблема автора, что он решил сделать логическую ошибку с апеляцией к собственному авторитету и вступить в дискуссию с несогласными на неформальных началах. В принципе, я еще недосмотрел саму дискуссию, но скорее всего она закончилась как дискуссии Сократа. Стороны перекатились из одной темы к другой, особо не придя к единому мнению и посмотрели на это с разных баррикад. Что для некоторых не особо будет продуктивно.
![Chino Pacas - Modo Capone (with Drake & Fuerza Regida) [Video Oficial]](http://i.ytimg.com/vi/zjv8TQ0gBkg/mqdefault.jpg)
Я поставил лайк за смелость. Доклад мне показался интересным в плане эксперимента. Эдакий живой диалог. Тут нужна подготовленная публика (возможно, на это был расчет), да и докладчик должен быть с погонами и увешан орденами боевых действий. Но получилось так, будт-то чувак бросился в ров с полу-сытыми львами и пытается отбиваться от взмахов их лап, отделался царапинами. Очень напряженная картина, я переживал. Но докладчику я желаю не опускать руки, учиться на ошибках.
Послушал еще раз. Докладчик в 10 минут рассказал основы 3d и все сказал верно в общем-то. И акцент все же на вопросах - т.е. задача была навести актуальный порядок в понимании темы у слушателей. Публика молодцом - задавали хорошие вопросы. Дмитрий молодец - кратко и по делу... Интересно - какая обстановка сейчас с внедрением 3д в "новом" проекте?
Для старта в DDD то что нужно!
Докладчик перепутал определения сабдоменов и ограниченных контекстов. В красной книге Вона Вернона (на которую докладчик ссылался в начале) ясно написано, что сабдомены (подобласти) являются областью ЗАДАЧ, то есть то, что хочет сделать бизнес. Ограниченные контексты представляют собой область РЕШЕНИЙ, куда входит МОДЕЛЬ ПРЕДМЕТНОЙ ОБЛАСТИ (а точнее модель подобласти, если контекст входит в эту подобласть, см рисунок на слайде), и все что определяется моделью - сервисы приложения, отображение(UI) и так далее.
TLTR; ДДД - это ..., но не работает потому что сложна, ваши вопросы)
Database lead в 2020?
Действительно, попытка упрощения сложного. Спасибо
Вооода, тем кто не понимает о чем речь, по докладу суть не понять...
I know Im kinda randomly asking but do anyone know of a good website to stream newly released series online ?
@Bentlee Remy Try flixzone. Just search on google for it =)
@Jad Kylan Yup, I've been watching on Flixzone for since march myself :)
@Jad Kylan Thank you, I went there and it seems like they got a lot of movies there =) I really appreciate it !
@Bentlee Remy No problem :)
Bounded context вообще не раскрыт
Мне одному режет слух домен и поддомены эх
Послушал 10 раз, но так и не понял разницу между subdomain и bounded context...
Первое это "программное выражение бизнес ценностей"
А второе - "бизнес функционал, описанный аналитиками"
наоборот, докладчик напутал
Как-то не серьёзно. Тема обширная, громкое название, а внутри доклад на 10 минут и на два с половиной так себе слайда. Наверное, рассказчик не успел нормально подготовиться.
Это чё за Вьетнам в вакууме?😅
Везде абстрактные примеры. Видео с кодом, хотя бы с псевдо, ещё не находил :(
Лайк)
новичкам тут ловить нечего. лучше посмотрите у АйТиБорода норм про Ddd
называется не разобрался в DDD - а уже на конференцию приехал и начал всем доносить что DDD не торт.
скоро надо будет вводить модерацию вот таких вот "спецов" - чтобы не позорились.
Был бы не плохо, если бы ваша критика была бы более предметная.
@@IliaGlazkov можно было упомянуть, что сам Эванс приводит, что внедрение всех принципов или большинства аспектов изложенных им (считать DDD), увеличивает трудозатраты в разы. Эванс говорит, что допускается использовать в DDD подобных системах срезы в виде используемых фреймворков для сокращения трудозатрат на разработку. Это тонкая грань без формализованных критериев когда нужно в DDD и когда не нужно в DDD.
Хотелось бы, судя по 11 минутам доклада, чтобы его автор привел критерии или примеры избыточности DDD, если мы говорим о цели доклада. Нельзя сказать тезис без доказательства людям, которые тезис считают ложным. Тогда не придется оспаривать сам тезис, а придется обсуждать (не)состоятельность аргументов.
Как можно доказать, что DDD не работает. Можно начать с утверждения, что DDD - это идеал системы, к которой можно стремиться, но он не достижим по ряду объективных причин (критериев). Критерий первый - трудозатраты и срочность разработки. Можно провести эксперимент, где две команды разработчиков с одинаковой квалификацией пишут одну и туже задачу в сжатые сроки. Разница между ними, что одна команда пишет все по заветам DDD, а другая не обязана им следовать. Затем экспертная комиссия может оценить работы участников на читаемость, поддерживаемость, производительность, подставьте нужное.
Можно подойти с другой стороны и заявить, что DDD из-за своей неформальности является философской идеей и не может быть формально описано. А раз неформальное, то не может быть достигнуто. Разработчики будут вечно недовольные, другие разработчики будут спорить что у них DDD, а у вас не DDD, и так далее...
Проблема автора, что он решил сделать логическую ошибку с апеляцией к собственному авторитету и вступить в дискуссию с несогласными на неформальных началах. В принципе, я еще недосмотрел саму дискуссию, но скорее всего она закончилась как дискуссии Сократа. Стороны перекатились из одной темы к другой, особо не придя к единому мнению и посмотрели на это с разных баррикад. Что для некоторых не особо будет продуктивно.
Особенно "выхлоп" нелепо звучит.
DDD утопия созданая от делать нехерство
Это неправильный Дмитрий Елисеев!
rd
"Мы придумали микросервисы"?
эмм