В докладе айспринг мне понравилась мысль о том что после DDD образуется проблема EDA. Но не все доходят до этого. Далее идет акцент на EDA.
Потому вероятно лучше заменить термин DDD на модули.
Но у них много схожих и важных идей: важность определения границы доменов будет звучать как важность определения границ модулей.
Первопричина изменения модуля и домена тоже совпадают. Модули также базируются на идеи первопричины изменения. Но кроме того там еще есть цель делать модули по командам. Чтобы команда могла работать в границах 1 модуля.
В моем понимании это все схожие идеи и понятия. Но коли это вводит такую путаницу и резкую реакцию, то легче поменять термин, чем пытаться спорить )
Если это столь больно бьет по чувствам верующих, то попробую поменять термин DDD на модули.
Это будет ближе к той мысли, которую озвучил Алан Кей, о том что расширяемые архитектуры базируются на модули, и надо думать не о модулях, а о том как модули взаимодействуют — обмен сообщениями.
Но видел ряд статей и видео о опыте реализации DDD по его книге. Мне не зашло.
Однако опыт с видео айспринг мне зашёл. И там речь тоже о DDD…
Вообще мне кажется что не бывает одного правильного подхода. Это скорее некая идеология и набор шаблонов. А в процессе реализации оно может принимать огромное количество форм и вариаций.
Потому я скорее предпочитаю изучать и размышлять о конкретной вариации которая ближе всего к моим проблемам и стеку. Например вариант реализации в айспринг.
Если он будет в чём то противоречить идеям Эванса, то я все равно предпочту опираться на него.
Пока не увижу опыт аналогичного качества который будет ближе к Эвансу.
А можно мне показать где в статье антихрупкость возведена в абсолют?
Да, согласно автору, в антихрупкости есть такая штука, что не существует метрик и возможностей ее измерить.
Есть лишь возможность сравнивать 2 системы относительно 1 события и говорить о том какая из них более или менее хрупка относительного указанного события.
И в моей практике была такая возможность. Были 2 команды, которые делали магазин. Одна на пхп, с доменами и событиями. Вторая на ноде с асинхронностью. Первая двигалась очень быстро, быстро дошла до результата и показала очень крутые метрики прибыли. Вторая команда двигалась очень медленно, постоянно спотыкалась и в какой то момент проект пришлось закрыть, а команду уволить.
Проблемы были плюс минус те же самые — не ясность требований, частое изменение задач, слабые процессы постановки задач. Все это плохо влияло на продукты. Но вот хрупкий продукт умер, а антихрупкий — выжил и показал отличные результаты.
Компетенции команд тоже были плюс минус похожие. Команда с нодой регулярно говорила о том что пхп дно и что будущее за нодой ) Вот только реальность оказалась иной )
Я не готов говорить за понимание Эванса. Также не готов говорить про SmallTalk. Потому что это все далеко и где то в другом мире.
Я предпочитаю говорить о практиках, которые можно пощупать, почитать код, проверить как это летает в реальной жизни. Иначе можно легко уйти в дебри теорий, заблудиться в фракталах терминологии.
В программировании вообще мало чего точного. Все очень спорно :)
Я не готов говорить за кого то и за чье то понимание DDD.
Конкретно в контексте статьи мне понравился доклад iSpring. Они говорят что это DDD. Разбитие функционала на модули и общение модулей через события.
Эти же качества я вижу в Фрискаут, в Редмайн, в WHMCS и многих других продуктах.
Для меня DDD это разбиение системы на модули, которые обмениваются друг с другом через сообщения EDA (события, триггеры, хуки). Возможно есть какие то еще вариации, но мне достаточно этого для решения тех проблем, которые встречаю в разработке.
Может быть конечно что то не так с гитарой и DDD. Это не идеальный инструмент и в нем тоже есть куча проблем. Также есть много команд и задач, где это не подходящий инструмент. Я не говорю о том что всем надо это использовать.
Речь конкретно о HighExtensible системах, где важно обеспечивать взаимодействие модулей, команд, переиспользовать код, перестать толкаться локтями и конфликтовать в GIT. В этих кейса DDD при правильном применении очень сильно помогают.
Опять же мне понравилась мысль в опыте iSpring о том что важно чертить границы доменов правильно. Ошибка в границах домена — приведет к проблемам.
В общем в этом мире не все всегда и везде, а кое что иногда и местами :)
> Видел упоротых по DDD людей, которые невероятно гордились тем, что для каждой сущности создавали доменный объект
Да, упоротые люди есть везде ) И я тоже видел много историй про DDD которые были очень далеки от реальности. От которых было проблем больше чем пользы.
Тоже самое можно сказать про типы, микросервисы, докеры, эджайл, скрам и т. д.
Абсолютно любой инструмент можно использовать так чтобы прострелить себе ноги и убить проект.
Наличие гитары в руках, даже если она самая лучшая в мире — не гарантирует что получится крутая музыка.
Потому тут речь идет о тех кейсах, где есть интересный и успешный опыт.
Я свои примеры привел. Те что мне понравились. И за которыми я наблюдаю.
Если есть крутые примеры — будет интересно узнать.
Если речь о том что где то плохо, и где то живут дураки — ну ок. Бывает. Зачем это изучать и на это тратить время?
Если взять только динамическую типизацию в вакууме то она мало на что влияет. И скорее всего никак не связана с антихрупкостью.
В статье речь об обратном. о том чтобы построить антихрупкую систему, то надо копать в сторону DDD & EDA. Это основа.
И вот там те кто проходят этот этап начинают отмечать что динамическая типизация удобнее и проще. Это отмечает Алан Кей, Дэвид Уэст, и тот же момент отмечается на видео про iSpring. Я тоже к этому выводу пришел.
Но если больно об этом думать, то можно и на статической. Однако в полной мере это получится сравнить когда получится поработать с системами которые глубоко используют DDD & EDA. Сравнить большие системы с динамической и статической типизацией в реальных боевых условиях.
Нода замечательно расширяется. Сишарп быстрый.
У меня нет возражений к этому.
Вообще расширяемую систему можно построить на любом языке. Как и сделать быстрый хайлоад микросервис.
В таблице я привёл своё видение и свои наблюдения о том что чаще в какой практик используется.
Это не значит что нельзя делать иначе. Можно. Если осторожно.
Однако в моей практие были печальные истории когда попытки сделать интернет магазин на ноде приводили очень к большим затратам и провалу проекта. Хотя по соседству такая же команда с такой же задачей на пхп двигалась сильно быстрее.
Плюс изучение практик и рынка показывает что модульные и расширяемые системы чаще живут на пхп. На ноде тоже конечно есть примеры, но их меньше и они проще по функционалу.
Сишарп не беру тк на нем мало примеров в опенсорсе. И я не силен в нём. Но сомневаюсь что он как то сильно отличается от пхп в данном контексте.
Динамическая и статическая типизация тоже очень условное и примерное деление.
Я за статическую типизацию в части ХЛ, потому что там меньше риск утечки памяти и по моим наблюдениям такие решения работают эффективнее и быстрее.
Однако разделяю точку зрения Алана Кея о том что это больно и что динамическая типизация в системах сложной бизнес логики даёт больше гибкости, антихрупкости.
То что какие то языки поддерживают или не поддерживают это второстепенно. Зачастую почти везде можно выбирать как писать код. Но даже если нельзя то это не самое страшное. И не самое важное.
Ключевое там это домены и события. Просто если в дополнение к ним можно уйти от жёстких типов это даёт плюс к гибкости. Этот момент также отметила докладчик из видео про опыт ispring.
Обмен сообщениями через кафку это скорее про очереди и многопоточность.
Обмен сообщениями через хуки, события и триггеры это другая механика.
Есть конечно и смешанные истории. Например мессенджер в симфони можно применять для построения обоих механик. Но это в теории. Хороших и интересных примеров построения EDA как механизма взаимодействия модулей через эту штуку я не встречал. Например уровня зрелости как из примера с фрискаут и эвенти.
Мысль о том что C# .net, Java spring, php symfony часто используют для создания расширяемых систем взял из своего опыта и тех мыслей что озвучили ребята на митапе skyeng, ссылка в статье.
Другая сторона баррикад это лишь условность. Популярность применения технологии для соответствующей практики.
Конечно есть хайлоад микросервисы на си шарп, яве или симфони.
Конечно есть попытки делать интернет магазины на nodejs.
Но мой опыт и мои ощущения говорят о том что часто это походит на попытку чесать ногой за ухом. Можно, но больно и не удобно.
Если же бизнес систему, панель управления, делают на Симфони, а какие то хайлоад запросы переводят на go, nodejs, или php roadrunner, то получается лучше.
Опять же это лишь мои наблюдения из моего опыта. Они могу не отражать всей реальности. Может быть много исключений.
Если будут какие то обратные примеры из реального опыта, то будет интересно узнать о них.
Оценки это плохо.
Оценки это хорошо.
Оба утверждения правильные. Вопрос контекста и кто делает.
В начале статьи автор пишет о том что скрам требует в спринт вкладывать не больше чем команда унесет. У этого правила есть много вариантов толкования и исполнения. Есть те которые приводят к дичи и проблемам. Есть те которые приводят к прогнозируемости и снижению рисков.
Заставь дурака богу молиться — он себе лоб расшибет.
Тоже самое с оценками в разработке.
Оценки бывают полезны, в ситуации когда клиенту, инвестору или руководству нужно понять инвестировать в задачу/проект или нет. Например если задача стоит пол года и 1 млн долларов то да, а если 12 месяцев и 4 млн долларов то нет.
Ну или чтобы понять что мы можем успеть к 1 января, а что нет? Что отбросить? А на чем фокусировать силы команды?
Другой момент когда «эффективные менеджеры» начинают оценивать сроки по задачам. Типа вот у нас 100 задач и каждой задаче надо поставить срок. А потом прививать «комплекс вины» разработчикам и заставлять их через манипуляции работать в выходные.
Ну или есть 1000 других вариантов разбить себе лоб и ушатать команду. Делая оценки сроков без смысла и понимания.
В докладе айспринг мне понравилась мысль о том что после DDD образуется проблема EDA. Но не все доходят до этого. Далее идет акцент на EDA.
Потому вероятно лучше заменить термин DDD на модули.
Но у них много схожих и важных идей: важность определения границы доменов будет звучать как важность определения границ модулей.
Первопричина изменения модуля и домена тоже совпадают. Модули также базируются на идеи первопричины изменения. Но кроме того там еще есть цель делать модули по командам. Чтобы команда могла работать в границах 1 модуля.
В моем понимании это все схожие идеи и понятия. Но коли это вводит такую путаницу и резкую реакцию, то легче поменять термин, чем пытаться спорить )
Если это столь больно бьет по чувствам верующих, то попробую поменять термин DDD на модули.
Это будет ближе к той мысли, которую озвучил Алан Кей, о том что расширяемые архитектуры базируются на модули, и надо думать не о модулях, а о том как модули взаимодействуют — обмен сообщениями.
Но видел ряд статей и видео о опыте реализации DDD по его книге. Мне не зашло.
Однако опыт с видео айспринг мне зашёл. И там речь тоже о DDD…
Вообще мне кажется что не бывает одного правильного подхода. Это скорее некая идеология и набор шаблонов. А в процессе реализации оно может принимать огромное количество форм и вариаций.
Потому я скорее предпочитаю изучать и размышлять о конкретной вариации которая ближе всего к моим проблемам и стеку. Например вариант реализации в айспринг.
Если он будет в чём то противоречить идеям Эванса, то я все равно предпочту опираться на него.
Пока не увижу опыт аналогичного качества который будет ближе к Эвансу.
Вот как то так )
Да, согласно автору, в антихрупкости есть такая штука, что не существует метрик и возможностей ее измерить.
Есть лишь возможность сравнивать 2 системы относительно 1 события и говорить о том какая из них более или менее хрупка относительного указанного события.
И в моей практике была такая возможность. Были 2 команды, которые делали магазин. Одна на пхп, с доменами и событиями. Вторая на ноде с асинхронностью. Первая двигалась очень быстро, быстро дошла до результата и показала очень крутые метрики прибыли. Вторая команда двигалась очень медленно, постоянно спотыкалась и в какой то момент проект пришлось закрыть, а команду уволить.
Проблемы были плюс минус те же самые — не ясность требований, частое изменение задач, слабые процессы постановки задач. Все это плохо влияло на продукты. Но вот хрупкий продукт умер, а антихрупкий — выжил и показал отличные результаты.
Компетенции команд тоже были плюс минус похожие. Команда с нодой регулярно говорила о том что пхп дно и что будущее за нодой ) Вот только реальность оказалась иной )
Я предпочитаю говорить о практиках, которые можно пощупать, почитать код, проверить как это летает в реальной жизни. Иначе можно легко уйти в дебри теорий, заблудиться в фракталах терминологии.
Например мне в свое время понравилась эта статья dev.to/kmruiz/to-domain-driven-design-6ao — согласен с автором. Перекликается с моим опытом.
Но даже эта статья далека, и сложно проверить на сколько хорошо работают идеи и решают ли они обозначенную проблематику?
А вот видео ребят из скайэнга прям очень супер крутое www.youtube.com/watch?v=xT25xiKqPcI
То как там понимается DDD & EDA — также перекликается с моим пониманием. Плюс решает именно те проблемы, над которым у меня сейчас болит голова.
Если я художник и я так вижу, а также то же видят другие художники, у которых есть реальный практический опыт решения этих проблем — ну ок.
Если нужно говорить об Эвансе, то хочется начать с примеров как и где эти идеи помогли решить обозначенные проблемы?
Я не готов говорить за кого то и за чье то понимание DDD.
Конкретно в контексте статьи мне понравился доклад iSpring. Они говорят что это DDD. Разбитие функционала на модули и общение модулей через события.
Эти же качества я вижу в Фрискаут, в Редмайн, в WHMCS и многих других продуктах.
Для меня DDD это разбиение системы на модули, которые обмениваются друг с другом через сообщения EDA (события, триггеры, хуки). Возможно есть какие то еще вариации, но мне достаточно этого для решения тех проблем, которые встречаю в разработке.
Может быть конечно что то не так с гитарой и DDD. Это не идеальный инструмент и в нем тоже есть куча проблем. Также есть много команд и задач, где это не подходящий инструмент. Я не говорю о том что всем надо это использовать.
Речь конкретно о HighExtensible системах, где важно обеспечивать взаимодействие модулей, команд, переиспользовать код, перестать толкаться локтями и конфликтовать в GIT. В этих кейса DDD при правильном применении очень сильно помогают.
Опять же мне понравилась мысль в опыте iSpring о том что важно чертить границы доменов правильно. Ошибка в границах домена — приведет к проблемам.
В общем в этом мире не все всегда и везде, а кое что иногда и местами :)
Да, упоротые люди есть везде ) И я тоже видел много историй про DDD которые были очень далеки от реальности. От которых было проблем больше чем пользы.
Тоже самое можно сказать про типы, микросервисы, докеры, эджайл, скрам и т. д.
Абсолютно любой инструмент можно использовать так чтобы прострелить себе ноги и убить проект.
Наличие гитары в руках, даже если она самая лучшая в мире — не гарантирует что получится крутая музыка.
Потому тут речь идет о тех кейсах, где есть интересный и успешный опыт.
Я свои примеры привел. Те что мне понравились. И за которыми я наблюдаю.
Если есть крутые примеры — будет интересно узнать.
Если речь о том что где то плохо, и где то живут дураки — ну ок. Бывает. Зачем это изучать и на это тратить время?
Если взять только динамическую типизацию в вакууме то она мало на что влияет. И скорее всего никак не связана с антихрупкостью.
В статье речь об обратном. о том чтобы построить антихрупкую систему, то надо копать в сторону DDD & EDA. Это основа.
И вот там те кто проходят этот этап начинают отмечать что динамическая типизация удобнее и проще. Это отмечает Алан Кей, Дэвид Уэст, и тот же момент отмечается на видео про iSpring. Я тоже к этому выводу пришел.
Но если больно об этом думать, то можно и на статической. Однако в полной мере это получится сравнить когда получится поработать с системами которые глубоко используют DDD & EDA. Сравнить большие системы с динамической и статической типизацией в реальных боевых условиях.
У меня нет возражений к этому.
Вообще расширяемую систему можно построить на любом языке. Как и сделать быстрый хайлоад микросервис.
В таблице я привёл своё видение и свои наблюдения о том что чаще в какой практик используется.
Это не значит что нельзя делать иначе. Можно. Если осторожно.
Однако в моей практие были печальные истории когда попытки сделать интернет магазин на ноде приводили очень к большим затратам и провалу проекта. Хотя по соседству такая же команда с такой же задачей на пхп двигалась сильно быстрее.
Плюс изучение практик и рынка показывает что модульные и расширяемые системы чаще живут на пхп. На ноде тоже конечно есть примеры, но их меньше и они проще по функционалу.
Сишарп не беру тк на нем мало примеров в опенсорсе. И я не силен в нём. Но сомневаюсь что он как то сильно отличается от пхп в данном контексте.
Я за статическую типизацию в части ХЛ, потому что там меньше риск утечки памяти и по моим наблюдениям такие решения работают эффективнее и быстрее.
Однако разделяю точку зрения Алана Кея о том что это больно и что динамическая типизация в системах сложной бизнес логики даёт больше гибкости, антихрупкости.
То что какие то языки поддерживают или не поддерживают это второстепенно. Зачастую почти везде можно выбирать как писать код. Но даже если нельзя то это не самое страшное. И не самое важное.
Ключевое там это домены и события. Просто если в дополнение к ним можно уйти от жёстких типов это даёт плюс к гибкости. Этот момент также отметила докладчик из видео про опыт ispring.
Обмен сообщениями через хуки, события и триггеры это другая механика.
Есть конечно и смешанные истории. Например мессенджер в симфони можно применять для построения обоих механик. Но это в теории. Хороших и интересных примеров построения EDA как механизма взаимодействия модулей через эту штуку я не встречал. Например уровня зрелости как из примера с фрискаут и эвенти.
Другая сторона баррикад это лишь условность. Популярность применения технологии для соответствующей практики.
Конечно есть хайлоад микросервисы на си шарп, яве или симфони.
Конечно есть попытки делать интернет магазины на nodejs.
Но мой опыт и мои ощущения говорят о том что часто это походит на попытку чесать ногой за ухом. Можно, но больно и не удобно.
Если же бизнес систему, панель управления, делают на Симфони, а какие то хайлоад запросы переводят на go, nodejs, или php roadrunner, то получается лучше.
Опять же это лишь мои наблюдения из моего опыта. Они могу не отражать всей реальности. Может быть много исключений.
Если будут какие то обратные примеры из реального опыта, то будет интересно узнать о них.
Оценки это хорошо.
Оба утверждения правильные. Вопрос контекста и кто делает.
В начале статьи автор пишет о том что скрам требует в спринт вкладывать не больше чем команда унесет. У этого правила есть много вариантов толкования и исполнения. Есть те которые приводят к дичи и проблемам. Есть те которые приводят к прогнозируемости и снижению рисков.
Заставь дурака богу молиться — он себе лоб расшибет.
Тоже самое с оценками в разработке.
Оценки бывают полезны, в ситуации когда клиенту, инвестору или руководству нужно понять инвестировать в задачу/проект или нет. Например если задача стоит пол года и 1 млн долларов то да, а если 12 месяцев и 4 млн долларов то нет.
Ну или чтобы понять что мы можем успеть к 1 января, а что нет? Что отбросить? А на чем фокусировать силы команды?
Другой момент когда «эффективные менеджеры» начинают оценивать сроки по задачам. Типа вот у нас 100 задач и каждой задаче надо поставить срок. А потом прививать «комплекс вины» разработчикам и заставлять их через манипуляции работать в выходные.
Ну или есть 1000 других вариантов разбить себе лоб и ушатать команду. Делая оценки сроков без смысла и понимания.