Комментарии 55
Ага, о том же хотел написать. HE это динамическая типизация (см. табличку), но в нее попали C# с Java. А вот HL статическая, но зато PHP, NodeJs. Классику жанра в виде С и C++ вообще забыли, хотя метод «переписать модуль на С» — это, как правило, достаточно радикальное решение боттлнеков. Ну и обмен сообщениями попал в HE… ну такое. В HL использовать кафку вполне себе вариант, чтобы сгладить пиковые нагрузки, и при этом расбросать поток на пул обработчиков.
Обмен сообщениями через кафку это скорее про очереди и многопоточность.
Обмен сообщениями через хуки, события и триггеры это другая механика.
Есть конечно и смешанные истории. Например мессенджер в симфони можно применять для построения обоих механик. Но это в теории. Хороших и интересных примеров построения EDA как механизма взаимодействия модулей через эту штуку я не встречал. Например уровня зрелости как из примера с фрискаут и эвенти.
Обмен сообщениями через хуки, события и триггеры это другая механика.
Есть конечно и смешанные истории. Например мессенджер в симфони можно применять для построения обоих механик. Но это в теории. Хороших и интересных примеров построения EDA как механизма взаимодействия модулей через эту штуку я не встречал. Например уровня зрелости как из примера с фрискаут и эвенти.
Динамическая и статическая типизация тоже очень условное и примерное деление.
Я за статическую типизацию в части ХЛ, потому что там меньше риск утечки памяти и по моим наблюдениям такие решения работают эффективнее и быстрее.
Однако разделяю точку зрения Алана Кея о том что это больно и что динамическая типизация в системах сложной бизнес логики даёт больше гибкости, антихрупкости.
То что какие то языки поддерживают или не поддерживают это второстепенно. Зачастую почти везде можно выбирать как писать код. Но даже если нельзя то это не самое страшное. И не самое важное.
Ключевое там это домены и события. Просто если в дополнение к ним можно уйти от жёстких типов это даёт плюс к гибкости. Этот момент также отметила докладчик из видео про опыт ispring.
Я за статическую типизацию в части ХЛ, потому что там меньше риск утечки памяти и по моим наблюдениям такие решения работают эффективнее и быстрее.
Однако разделяю точку зрения Алана Кея о том что это больно и что динамическая типизация в системах сложной бизнес логики даёт больше гибкости, антихрупкости.
То что какие то языки поддерживают или не поддерживают это второстепенно. Зачастую почти везде можно выбирать как писать код. Но даже если нельзя то это не самое страшное. И не самое важное.
Ключевое там это домены и события. Просто если в дополнение к ним можно уйти от жёстких типов это даёт плюс к гибкости. Этот момент также отметила докладчик из видео про опыт ispring.
Ну и, тут можно оценить некую общую картину. В топ5 C++, Rust, Java, C#
Мысль о том что C# .net, Java spring, php symfony часто используют для создания расширяемых систем взял из своего опыта и тех мыслей что озвучили ребята на митапе skyeng, ссылка в статье.
Другая сторона баррикад это лишь условность. Популярность применения технологии для соответствующей практики.
Конечно есть хайлоад микросервисы на си шарп, яве или симфони.
Конечно есть попытки делать интернет магазины на nodejs.
Но мой опыт и мои ощущения говорят о том что часто это походит на попытку чесать ногой за ухом. Можно, но больно и не удобно.
Если же бизнес систему, панель управления, делают на Симфони, а какие то хайлоад запросы переводят на go, nodejs, или php roadrunner, то получается лучше.
Опять же это лишь мои наблюдения из моего опыта. Они могу не отражать всей реальности. Может быть много исключений.
Если будут какие то обратные примеры из реального опыта, то будет интересно узнать о них.
Другая сторона баррикад это лишь условность. Популярность применения технологии для соответствующей практики.
Конечно есть хайлоад микросервисы на си шарп, яве или симфони.
Конечно есть попытки делать интернет магазины на nodejs.
Но мой опыт и мои ощущения говорят о том что часто это походит на попытку чесать ногой за ухом. Можно, но больно и не удобно.
Если же бизнес систему, панель управления, делают на Симфони, а какие то хайлоад запросы переводят на go, nodejs, или php roadrunner, то получается лучше.
Опять же это лишь мои наблюдения из моего опыта. Они могу не отражать всей реальности. Может быть много исключений.
Если будут какие то обратные примеры из реального опыта, то будет интересно узнать о них.
Нода замечательно расширяется. Сишарп быстрый.
У меня нет возражений к этому.
Вообще расширяемую систему можно построить на любом языке. Как и сделать быстрый хайлоад микросервис.
В таблице я привёл своё видение и свои наблюдения о том что чаще в какой практик используется.
Это не значит что нельзя делать иначе. Можно. Если осторожно.
Однако в моей практие были печальные истории когда попытки сделать интернет магазин на ноде приводили очень к большим затратам и провалу проекта. Хотя по соседству такая же команда с такой же задачей на пхп двигалась сильно быстрее.
Плюс изучение практик и рынка показывает что модульные и расширяемые системы чаще живут на пхп. На ноде тоже конечно есть примеры, но их меньше и они проще по функционалу.
Сишарп не беру тк на нем мало примеров в опенсорсе. И я не силен в нём. Но сомневаюсь что он как то сильно отличается от пхп в данном контексте.
У меня нет возражений к этому.
Вообще расширяемую систему можно построить на любом языке. Как и сделать быстрый хайлоад микросервис.
В таблице я привёл своё видение и свои наблюдения о том что чаще в какой практик используется.
Это не значит что нельзя делать иначе. Можно. Если осторожно.
Однако в моей практие были печальные истории когда попытки сделать интернет магазин на ноде приводили очень к большим затратам и провалу проекта. Хотя по соседству такая же команда с такой же задачей на пхп двигалась сильно быстрее.
Плюс изучение практик и рынка показывает что модульные и расширяемые системы чаще живут на пхп. На ноде тоже конечно есть примеры, но их меньше и они проще по функционалу.
Сишарп не беру тк на нем мало примеров в опенсорсе. И я не силен в нём. Но сомневаюсь что он как то сильно отличается от пхп в данном контексте.
Динамическая типизация — это антихрупкость? Как так вышло?
Я не в курсе )
Если взять только динамическую типизацию в вакууме то она мало на что влияет. И скорее всего никак не связана с антихрупкостью.
В статье речь об обратном. о том чтобы построить антихрупкую систему, то надо копать в сторону DDD & EDA. Это основа.
И вот там те кто проходят этот этап начинают отмечать что динамическая типизация удобнее и проще. Это отмечает Алан Кей, Дэвид Уэст, и тот же момент отмечается на видео про iSpring. Я тоже к этому выводу пришел.
Но если больно об этом думать, то можно и на статической. Однако в полной мере это получится сравнить когда получится поработать с системами которые глубоко используют DDD & EDA. Сравнить большие системы с динамической и статической типизацией в реальных боевых условиях.
Если взять только динамическую типизацию в вакууме то она мало на что влияет. И скорее всего никак не связана с антихрупкостью.
В статье речь об обратном. о том чтобы построить антихрупкую систему, то надо копать в сторону DDD & EDA. Это основа.
И вот там те кто проходят этот этап начинают отмечать что динамическая типизация удобнее и проще. Это отмечает Алан Кей, Дэвид Уэст, и тот же момент отмечается на видео про iSpring. Я тоже к этому выводу пришел.
Но если больно об этом думать, то можно и на статической. Однако в полной мере это получится сравнить когда получится поработать с системами которые глубоко используют DDD & EDA. Сравнить большие системы с динамической и статической типизацией в реальных боевых условиях.
построить антихрупкую систему, то надо копать в сторону DDD
Видел упоротых по DDD людей, которые невероятно гордились тем, что для каждой сущности создавали доменный объект (для отработки бизнес логики), суррогат (для сериализации и десериализации из json для хранения в MongoDB), модель (для передачи по сети), конверторы (суррогат <-> объект <-> модель). Разумеется, работа с базой шла исключительно через репозиторий (отдельный для каждой сущности). Чтобы сделать минимальную операцию бизнес-логики, необходимо было извлечь json всех необходимых объектов из БД, десериализовать их в суррогат, преоразовать суррогат в объект, и вызвать метод. Также у них был документ в конфлюэнсе под названием ubiquitous language, где были бережно выписаны все сущности реального мира, которые участвуют в бизнес процессе.
И вот, видя это все, могу с полной уверенностью утверждать, что антихрупкость не про это. Потому, что подобная система настолько заточена под конкрентный, закладываемый при написании, бизнес-процесс, что проявляет абсолютную беспомощность, когда вдруг надо реализовать прорывную, никак не предусматриваемую изначальным процессом, идею.
А вот системы, которые опираются на SQL хранилища, напротив, демонстрируют невороятную антихрупкость, ведь позволяют в один запрос извлекать невообразимые ранее свойства системы, позволяя конструировать новые сущности, до которых не додумывались в реальном бизнес-процессе, на лету.
Поэтому, лично для себя я сделал вывод, что DDD, — это, как поддержки для велосипеда. Он не позволит трейни и джунам написать полную дичь (которая запросто пишется при data-centric подходе, например), и при этом позволяет таким же новым трейни быстро понять шаблон. Но при этом, ни об эффективности, ни об антихрупкости говорить не приходится. Точно так же, как и странно на велосипеде с поддержками ставить рекорды на велотреке.
> Видел упоротых по DDD людей, которые невероятно гордились тем, что для каждой сущности создавали доменный объект
Да, упоротые люди есть везде ) И я тоже видел много историй про DDD которые были очень далеки от реальности. От которых было проблем больше чем пользы.
Тоже самое можно сказать про типы, микросервисы, докеры, эджайл, скрам и т. д.
Абсолютно любой инструмент можно использовать так чтобы прострелить себе ноги и убить проект.
Наличие гитары в руках, даже если она самая лучшая в мире — не гарантирует что получится крутая музыка.
Потому тут речь идет о тех кейсах, где есть интересный и успешный опыт.
Я свои примеры привел. Те что мне понравились. И за которыми я наблюдаю.
Если есть крутые примеры — будет интересно узнать.
Если речь о том что где то плохо, и где то живут дураки — ну ок. Бывает. Зачем это изучать и на это тратить время?
Да, упоротые люди есть везде ) И я тоже видел много историй про DDD которые были очень далеки от реальности. От которых было проблем больше чем пользы.
Тоже самое можно сказать про типы, микросервисы, докеры, эджайл, скрам и т. д.
Абсолютно любой инструмент можно использовать так чтобы прострелить себе ноги и убить проект.
Наличие гитары в руках, даже если она самая лучшая в мире — не гарантирует что получится крутая музыка.
Потому тут речь идет о тех кейсах, где есть интересный и успешный опыт.
Я свои примеры привел. Те что мне понравились. И за которыми я наблюдаю.
Если есть крутые примеры — будет интересно узнать.
Если речь о том что где то плохо, и где то живут дураки — ну ок. Бывает. Зачем это изучать и на это тратить время?
Я свои примеры привел. Те что мне понравились.
Точно ли это DDD? Архитектуры с плагинами (в основном в десктоп приложениях для продвинутых юзеров) были распространены задолго до того, как DDD стал мейнстримом. К примеру, Far Manager. Сомневаюсь, что если открыть классику жанра вроде DDD Эрика Эванса и исходники подобного софта, то выйдет найти много общего.
Если же вы интуитивно вкладываете в понятие DDD инкапсуляцию, модульность и здравый смысл, то, наверное, стоит это называть это по-своему.
Наличие гитары в руках, даже если она самая лучшая в мире — не гарантирует что получится крутая музыка.
Развивая эту аналогию, я привел в пример не просто ребят, которые не умеют играть, а которые досконально выучили теорию, отработали сотни часов тренировок на гитаре, сдали экзамены в музыкальной школе на отлично, но вот все равно выходит какофония. Может все же в этом случае что-то с гитарой не так?
В программировании вообще мало чего точного. Все очень спорно :)
Я не готов говорить за кого то и за чье то понимание DDD.
Конкретно в контексте статьи мне понравился доклад iSpring. Они говорят что это DDD. Разбитие функционала на модули и общение модулей через события.
Эти же качества я вижу в Фрискаут, в Редмайн, в WHMCS и многих других продуктах.
Для меня DDD это разбиение системы на модули, которые обмениваются друг с другом через сообщения EDA (события, триггеры, хуки). Возможно есть какие то еще вариации, но мне достаточно этого для решения тех проблем, которые встречаю в разработке.
Может быть конечно что то не так с гитарой и DDD. Это не идеальный инструмент и в нем тоже есть куча проблем. Также есть много команд и задач, где это не подходящий инструмент. Я не говорю о том что всем надо это использовать.
Речь конкретно о HighExtensible системах, где важно обеспечивать взаимодействие модулей, команд, переиспользовать код, перестать толкаться локтями и конфликтовать в GIT. В этих кейса DDD при правильном применении очень сильно помогают.
Опять же мне понравилась мысль в опыте iSpring о том что важно чертить границы доменов правильно. Ошибка в границах домена — приведет к проблемам.
В общем в этом мире не все всегда и везде, а кое что иногда и местами :)
Я не готов говорить за кого то и за чье то понимание DDD.
Конкретно в контексте статьи мне понравился доклад iSpring. Они говорят что это DDD. Разбитие функционала на модули и общение модулей через события.
Эти же качества я вижу в Фрискаут, в Редмайн, в WHMCS и многих других продуктах.
Для меня DDD это разбиение системы на модули, которые обмениваются друг с другом через сообщения EDA (события, триггеры, хуки). Возможно есть какие то еще вариации, но мне достаточно этого для решения тех проблем, которые встречаю в разработке.
Может быть конечно что то не так с гитарой и DDD. Это не идеальный инструмент и в нем тоже есть куча проблем. Также есть много команд и задач, где это не подходящий инструмент. Я не говорю о том что всем надо это использовать.
Речь конкретно о HighExtensible системах, где важно обеспечивать взаимодействие модулей, команд, переиспользовать код, перестать толкаться локтями и конфликтовать в GIT. В этих кейса DDD при правильном применении очень сильно помогают.
Опять же мне понравилась мысль в опыте iSpring о том что важно чертить границы доменов правильно. Ошибка в границах домена — приведет к проблемам.
В общем в этом мире не все всегда и везде, а кое что иногда и местами :)
Для меня DDD это разбиение системы на модули, которые обмениваются друг с другом через сообщения EDA (события, триггеры, хуки).
Это очень удобно, брать аббривеатуру и придумывать свои определения, «я художник, я так вижу». Мы так ни о чем не договоримся, максимум приятно пофлудим.
DDD у Эванса описано и это точно не то, что вы говорите. Идея разбить систему на модули и обмениваться сообщениями была ещё в 60х в SmallTalk.
Я не готов говорить за понимание Эванса. Также не готов говорить про SmallTalk. Потому что это все далеко и где то в другом мире.
Я предпочитаю говорить о практиках, которые можно пощупать, почитать код, проверить как это летает в реальной жизни. Иначе можно легко уйти в дебри теорий, заблудиться в фракталах терминологии.
Например мне в свое время понравилась эта статья dev.to/kmruiz/to-domain-driven-design-6ao — согласен с автором. Перекликается с моим опытом.
Но даже эта статья далека, и сложно проверить на сколько хорошо работают идеи и решают ли они обозначенную проблематику?
А вот видео ребят из скайэнга прям очень супер крутое www.youtube.com/watch?v=xT25xiKqPcI
То как там понимается DDD & EDA — также перекликается с моим пониманием. Плюс решает именно те проблемы, над которым у меня сейчас болит голова.
Если я художник и я так вижу, а также то же видят другие художники, у которых есть реальный практический опыт решения этих проблем — ну ок.
Если нужно говорить об Эвансе, то хочется начать с примеров как и где эти идеи помогли решить обозначенные проблемы?
Я предпочитаю говорить о практиках, которые можно пощупать, почитать код, проверить как это летает в реальной жизни. Иначе можно легко уйти в дебри теорий, заблудиться в фракталах терминологии.
Например мне в свое время понравилась эта статья dev.to/kmruiz/to-domain-driven-design-6ao — согласен с автором. Перекликается с моим опытом.
Но даже эта статья далека, и сложно проверить на сколько хорошо работают идеи и решают ли они обозначенную проблематику?
А вот видео ребят из скайэнга прям очень супер крутое www.youtube.com/watch?v=xT25xiKqPcI
То как там понимается DDD & EDA — также перекликается с моим пониманием. Плюс решает именно те проблемы, над которым у меня сейчас болит голова.
Если я художник и я так вижу, а также то же видят другие художники, у которых есть реальный практический опыт решения этих проблем — ну ок.
Если нужно говорить об Эвансе, то хочется начать с примеров как и где эти идеи помогли решить обозначенные проблемы?
Ору. Вы вообще понимаете, что DDD — термин, введенный Эвансом?
Любое другое понимание этого термина — это лишь попытка примазаться к известному термину.
Зачем вы используете термины, которых не понимаете?
Любое другое понимание этого термина — это лишь попытка примазаться к известному термину.
Зачем вы используете термины, которых не понимаете?
Не, не знал что он придумал термин.
Но видел ряд статей и видео о опыте реализации DDD по его книге. Мне не зашло.
Однако опыт с видео айспринг мне зашёл. И там речь тоже о DDD…
Вообще мне кажется что не бывает одного правильного подхода. Это скорее некая идеология и набор шаблонов. А в процессе реализации оно может принимать огромное количество форм и вариаций.
Потому я скорее предпочитаю изучать и размышлять о конкретной вариации которая ближе всего к моим проблемам и стеку. Например вариант реализации в айспринг.
Если он будет в чём то противоречить идеям Эванса, то я все равно предпочту опираться на него.
Пока не увижу опыт аналогичного качества который будет ближе к Эвансу.
Вот как то так )
Но видел ряд статей и видео о опыте реализации DDD по его книге. Мне не зашло.
Однако опыт с видео айспринг мне зашёл. И там речь тоже о DDD…
Вообще мне кажется что не бывает одного правильного подхода. Это скорее некая идеология и набор шаблонов. А в процессе реализации оно может принимать огромное количество форм и вариаций.
Потому я скорее предпочитаю изучать и размышлять о конкретной вариации которая ближе всего к моим проблемам и стеку. Например вариант реализации в айспринг.
Если он будет в чём то противоречить идеям Эванса, то я все равно предпочту опираться на него.
Пока не увижу опыт аналогичного качества который будет ближе к Эвансу.
Вот как то так )
Да по барабану, нравится ли вам DDD в понимании Эванса или нет. Вы или называете вещи своими именами или просто примазываетесь к термину. И то, что разработчики из iSpring возможно неправильно применяют этот термин — вам оправдания не делает.
Уже чисто по тому, как вы выворачиваете вопрос правильного именования становится ясно, что ваше DDD и близко к термину не относится. Ну кроме разве что некоторого набора практик, чисто внешнеё сходство и все.
Вопрос не в том, правильный подход или нет. Вопрос в терминах. Вы сможете без гугла ответить, в чем идеология DDD? Вы понимаете, что если {Something} Driven Development использует арифметические операторы, то это не делает арифметические операторы единственным определяющим аттрибутом {Something} Driven Development?
Уже чисто по тому, как вы выворачиваете вопрос правильного именования становится ясно, что ваше DDD и близко к термину не относится. Ну кроме разве что некоторого набора практик, чисто внешнеё сходство и все.
Вообще мне кажется что не бывает одного правильного подхода. Это скорее некая идеология и набор шаблонов. А в процессе реализации оно может принимать огромное количество форм и вариаций.
Вопрос не в том, правильный подход или нет. Вопрос в терминах. Вы сможете без гугла ответить, в чем идеология DDD? Вы понимаете, что если {Something} Driven Development использует арифметические операторы, то это не делает арифметические операторы единственным определяющим аттрибутом {Something} Driven Development?
Да, похоже уловил мысль.
Если это столь больно бьет по чувствам верующих, то попробую поменять термин DDD на модули.
Это будет ближе к той мысли, которую озвучил Алан Кей, о том что расширяемые архитектуры базируются на модули, и надо думать не о модулях, а о том как модули взаимодействуют — обмен сообщениями.
Если это столь больно бьет по чувствам верующих, то попробую поменять термин DDD на модули.
Это будет ближе к той мысли, которую озвучил Алан Кей, о том что расширяемые архитектуры базируются на модули, и надо думать не о модулях, а о том как модули взаимодействуют — обмен сообщениями.
Также не готов говорить про SmallTalk.
Это будет ближе к той мысли, которую озвучил Алан Кей, о том что расширяемые архитектуры базируются на модули, и надо думать не о модулях, а о том как модули взаимодействуют — обмен сообщениями.
Эванса не знаем, но знаем DDD. SmallTalk не знаем, но о высказываниях создателя SmallTalk Алана Кея знаем, забавно :)
Да, вот так вот ))
В общем поменял в статье акценты. Сделал больше упор на модульность. DDD это лишь одна из вариаций. Сама по себе имеет ценность, но далеко не везде.
Сделал больше акцента на модульность и сообщения.
На мой взгляд это именно то что нужно для расширяемых систем.
SmallTalk нафиг. Он может быть и крут, но толку от этого если сегодня другой мир и другие понятия.
Потому смотрим на что реально стреляет и применяется.
В общем поменял в статье акценты. Сделал больше упор на модульность. DDD это лишь одна из вариаций. Сама по себе имеет ценность, но далеко не везде.
Сделал больше акцента на модульность и сообщения.
На мой взгляд это именно то что нужно для расширяемых систем.
SmallTalk нафиг. Он может быть и крут, но толку от этого если сегодня другой мир и другие понятия.
Потому смотрим на что реально стреляет и применяется.
SmallTalk нафиг. Он может быть и крут, но толку от этого если сегодня другой мир и другие понятия.
Это где это сегодня другой мир? В комментариях к заметкам, сравнивающим ноду и похапе?
Очень трудно объяснить вкус дыни человеку, который всю жизнь жевал сапожные шнурки. — Виктор Шкловский
Понимаете, смешно слушать рассуждения про хайлоад и хрупкость от людей, которые никогда не сталкивались ни с тем, ни с другим (по крайней мере, на низком уровне). Взять кафку какую-нибудь — большого ума не надо, но хорошо бы при этом понимать, что это развитие идеи именно смолтолка.
Вотсап не случайно работает на эрланге, а эрланг (другие времена, хех?) — тот же смолтолк, только отказоустойчивый. Да, в энтерпрайзе другие священные коровы, но девять девяток не всякая джава потянет, не говоря про дотнет.
Так что «нафиг» отправлять прародителя всех систем, построенных на модели акторов — это очень странный подход. По крайней мере, в тексте, упоминающем HL и HA.
Идея разбить систему на модули и обмениваться сообщениями была ещё в 60х в SmallTalk.
Кей, конечно, тот еще старикан, но в шестидесятых он учил колорадских студентов играть джаз на гитаре, а потом — занимался FLEX. SmallTalk появился уже в семидесятых.
И не «на модули», а на «маленькие компьютерчики».
:)
Конкретно в контексте статьи мне понравился доклад iSpring. Они говорят что это DDD. Разбитие функционала на модули и общение модулей через события.
Вы услышали то, что хотели услышать. Там не сказано, что EDA (события, триггеры, хуки) — это DDD. DDD допускает событийную архитектуру, но оно не про это. DDD допускает разделение на модули, но оно тоже не про это. DDD как раз, с технической точки зрения, про стопятьсот слоёв абстракций, обеспечивающих, как побочный эффект, антихрупкость несколькими путями:
- разделение всего кода на слои, у которых разные причины для изменений, прежде всего у доменного слоя одна причина — изменения в предметной области ну, или, изменения в представлении разработчиков о предметной области. Ни смена посгтреса на монгу, ни переход с ларавел на симфони, ни переход на событийную архитектуру с прямой связи, ни обратный не должны менять слой domain.
- разделение всего кода на ограниченные контексты, в которых у каждой моделируемой сущности предметной области, своя техническая модель (которая даже именоватьсяя может по разному и быть семантически разными вещами, например, в одном контексте сущность, а в другом — объект-значение) и контексты отделены друг от друга, общаются только через строго определённые контракты
Да, возможно.
В докладе айспринг мне понравилась мысль о том что после DDD образуется проблема EDA. Но не все доходят до этого. Далее идет акцент на EDA.
Потому вероятно лучше заменить термин DDD на модули.
Но у них много схожих и важных идей: важность определения границы доменов будет звучать как важность определения границ модулей.
Первопричина изменения модуля и домена тоже совпадают. Модули также базируются на идеи первопричины изменения. Но кроме того там еще есть цель делать модули по командам. Чтобы команда могла работать в границах 1 модуля.
В моем понимании это все схожие идеи и понятия. Но коли это вводит такую путаницу и резкую реакцию, то легче поменять термин, чем пытаться спорить )
В докладе айспринг мне понравилась мысль о том что после DDD образуется проблема EDA. Но не все доходят до этого. Далее идет акцент на EDA.
Потому вероятно лучше заменить термин DDD на модули.
Но у них много схожих и важных идей: важность определения границы доменов будет звучать как важность определения границ модулей.
Первопричина изменения модуля и домена тоже совпадают. Модули также базируются на идеи первопричины изменения. Но кроме того там еще есть цель делать модули по командам. Чтобы команда могла работать в границах 1 модуля.
В моем понимании это все схожие идеи и понятия. Но коли это вводит такую путаницу и резкую реакцию, то легче поменять термин, чем пытаться спорить )
Я конечно не оправдываю overengineering, и три слоя объектов это реально перебор. Но вот ubiquitous language — действительно полезная штука. Особенно, когда она работает не только для разработчиков, но и для PM, тестеров, аналитиков. Потому что в противном случае появляется по два-три названия для одного и того же: одно в багтрекере, другое в документации, третье в коде.
Статья может быть и хорошая, но вы не понимаете, что такое антихрупкость и главный тезис в корне не верен.
Это из заголовка научной статьи Талеба по теме.
We provide a mathematical definition of fragility and antifragility as negative or positive sensitivity to a semi-measure of dispersion and volatility (a variant of negative or positive “vega”) and examine the link to nonlinear effects.
Антихрупкость это свойство объектов, обладающих вероятностным распределением. В контексте программ — хрупкость это когда для реализации небольшого требования нужно пол системы переделать. Я для любой программы смогу предложить такое требование, не важно, high-load, DDD, OOP, etc. Например — давайте запускать программу под DOS 1.0. Если программа (а скорее процесс разработки) антихрупкий, то вы автоматически, не прикладывая усилий, а просто следуя процессу, получаете бонусы.
Вот, автор иллюстрирует свою идею.
when systems – a building, a bridge, a nuclear plant, an airplane, or a bank balance sheet– are made robust to a certain level of variability and stress but may fail or collapse if this level is exceeded, then they are particularly fragile to uncertainty about the distribution of the stressor, hence to model error, as this uncertainty increases the probability of dipping below the robustness level, bringing a higher probability of collapse. In the opposite case, the natural selection of an evolutionary process is particularly antifragile, indeed, a more volatile environment increases the survival rate of robust species and eliminates those whose superiority over other species is highly dependent on environmental parameters.
То есть берём большую амплитуду силы землятресений — плохо для зданий и большую амплитуду изменений среды — хорошо для эволюции. А если я возьму большую вариативность архитектурных стилей для зданий и большой диапазон температур (от -273 до 1 000 000 C) для эволюции. Эволюция перестала быть антихрупкой и развалилась. Зато стало очевидно, что антихрупкость относительна, а один и тот же объект может быть хрупким и антихрупким одновременно. И этот ещё одна проблема с тезисом — вы вставляете относительную величину в абсолютное высказывание об эффективности и антихрупкости.
Научпоп это роман, вы же не учитесь фехтовать по «Трём мушкетерам», так вот не надо учиться проектировать по художественным книгам. Учите матан и читайте оригиналы толковых статей.
для реализации небольшого требования
давайте запускать программу под DOS 1.0
А кто сказал, что это небольшое требование?
А это на самом деле не важно. Важно только то, что если требования колбасит, то программе от этого плохо. Антихрупкой программе от этого должно быть хорошо, хотя бы до определенного предела. Сравните это с эволюцией, если взять за метрику супремум IQ популяции, то изменения среды это необходимый компонент его увеличения.
Тут ещё пара шагов до того, чтобы саму идею «анитихрупкости» начать серьезно критиковать.
А можно мне показать где в статье антихрупкость возведена в абсолют?
Да, согласно автору, в антихрупкости есть такая штука, что не существует метрик и возможностей ее измерить.
Есть лишь возможность сравнивать 2 системы относительно 1 события и говорить о том какая из них более или менее хрупка относительного указанного события.
И в моей практике была такая возможность. Были 2 команды, которые делали магазин. Одна на пхп, с доменами и событиями. Вторая на ноде с асинхронностью. Первая двигалась очень быстро, быстро дошла до результата и показала очень крутые метрики прибыли. Вторая команда двигалась очень медленно, постоянно спотыкалась и в какой то момент проект пришлось закрыть, а команду уволить.
Проблемы были плюс минус те же самые — не ясность требований, частое изменение задач, слабые процессы постановки задач. Все это плохо влияло на продукты. Но вот хрупкий продукт умер, а антихрупкий — выжил и показал отличные результаты.
Компетенции команд тоже были плюс минус похожие. Команда с нодой регулярно говорила о том что пхп дно и что будущее за нодой ) Вот только реальность оказалась иной )
Да, согласно автору, в антихрупкости есть такая штука, что не существует метрик и возможностей ее измерить.
Есть лишь возможность сравнивать 2 системы относительно 1 события и говорить о том какая из них более или менее хрупка относительного указанного события.
И в моей практике была такая возможность. Были 2 команды, которые делали магазин. Одна на пхп, с доменами и событиями. Вторая на ноде с асинхронностью. Первая двигалась очень быстро, быстро дошла до результата и показала очень крутые метрики прибыли. Вторая команда двигалась очень медленно, постоянно спотыкалась и в какой то момент проект пришлось закрыть, а команду уволить.
Проблемы были плюс минус те же самые — не ясность требований, частое изменение задач, слабые процессы постановки задач. Все это плохо влияло на продукты. Но вот хрупкий продукт умер, а антихрупкий — выжил и показал отличные результаты.
Компетенции команд тоже были плюс минус похожие. Команда с нодой регулярно говорила о том что пхп дно и что будущее за нодой ) Вот только реальность оказалась иной )
А можно мне показать где в статье антихрупкость возведена в абсолют?
Извиняюсь, если прозвучит немного грубо, но нужно читать, что написано, а не то, что вам хочется прочитать. Читать по буквам и внимательно, это непросто, но необходимо. Не возведение в абсолют, а «абсолютное высказывание». Это высказывание вида «для всех X (вообще) Y». А вот оно в статье
погоня за эффективностью всегда влечет рост хрупкости. Если мы ставим себе цель делать систему антихрупкой, нам придется жертвовать эффективностью. Иного не дано.
Другими словами «для всех систем (вообще) существует инвариант вида Хрупкость + Эффективность = const».
Да, согласно автору, в антихрупкости есть такая штука, что не существует метрик и возможностей ее измерить.
А здесь уже неверно прочитан текст Талеба. Вот скрин из него
Выше есть значки, с их помощью можно делать непротиворечивые утверждения. Другой способ — показать многократно повторенный эксперимент, в контролируемой среде. Все остальное это размахивание руками, разной степени полезности. Крайне желательно понимать, когда делаются утверждения, а когда происходит размахивание руками.
Но вот хрупкий продукт умер, а антихрупкий — выжил и показал отличные результаты.
Я не знаю как вы «анитихрупкость» применили к «системе», если автор явно говорит, что все это про распределения вероятностей.
Да, может быть формулировка не очень.
Вот цитаты:
> Хрупкость и антихрупкость здесь – относительные понятия, а не абсолютные качества: объект, находящийся справа от точки отсчета, более антихрупок, чем объект, который находится слева.
> Как видит читатель, карта без каких-либо ограничений распространяется на любые области и сферы деятельности: культура, здравоохранение, биология, политические системы, технология, городское планирование, социально-экономическая жизнь и прочие явления
Если карта хрупкости и антихрупкости применяется к любым объектам, вещам и системам, включая политические системы и технологии, то почему я не могу ее применить для программной системы?
Ту же стратегию штанги отлично получается применять к покеру. Это вообще очень гибкая теория и ее применение возможно в самых разных областях.
Вот цитаты:
> Хрупкость и антихрупкость здесь – относительные понятия, а не абсолютные качества: объект, находящийся справа от точки отсчета, более антихрупок, чем объект, который находится слева.
> Как видит читатель, карта без каких-либо ограничений распространяется на любые области и сферы деятельности: культура, здравоохранение, биология, политические системы, технология, городское планирование, социально-экономическая жизнь и прочие явления
Если карта хрупкости и антихрупкости применяется к любым объектам, вещам и системам, включая политические системы и технологии, то почему я не могу ее применить для программной системы?
Ту же стратегию штанги отлично получается применять к покеру. Это вообще очень гибкая теория и ее применение возможно в самых разных областях.
Если карта хрупкости и антихрупкости применяется к любым объектам, вещам и системам, включая политические системы и технологии, то почему я не могу ее применить для программной системы?
Можете и это даже имеет некоторый смысл. Но вы не можете противопоставлять антихрупкость и эффективность, в том смысле, в котором вы о них говорите в статье.
В книге Антихрупкость, автор Нассим Талеб пишет о том что погоня за эффективностью всегда влечет рост хрупкости. Если мы ставим себе цель делать систему антихрупкой, нам придется жертвовать эффективностью. Иного не дано.
На какие только ухищрения слов и терминов не идут программисты, лишь бы донести владельцам бизнесов простую мысль, что за скорость всегда приходится платить качеством
Это враньё программистов, которым они прикрывают свою неопытность. Возьмите команду, которая уже 20 лет делает ERP и они вам сделают ERP быстро, качественно и дешевле чем аналогичная команда с опытом создания 3D игр.
Они же сделают ещё быстрее и дешевле, если сказать, что качества особого не надо.
Если я знаю как решать задачу, я решаю ее а) быстро б) качественно в) относительно дешево (без переделок, задержек, потерянной прибыли и т.п.) Если же я не знаю как решать задачу, то я экспериментирую и получается а) долго б) так-себе по качеству в) дорого, по многим причинам. Возможно, кто-то умеет по другому, но я такого не видел. Поэтому я считаю (сужу по себе), что в программировании либо качественно/быстро/дешево, либо так-себе/дорого/долго.
У команды ERP, о которой речь, качество заложено в их библиотеках, подходах и опыте. Это не то, что вы сможете променять на скорость.
У команды ERP, о которой речь, качество заложено в их библиотеках, подходах и опыте. Это не то, что вы сможете променять на скорость.
You can both kept fault tolerance and scalability. You can have both or none of them. — Joe Armstrong
Просто удивительно, как в подобных — перегруженных цитатами из диванных теоретиков — статьях никто не удосуживается упомянуть Erlang/OTP. Вот два миллиона вебсокетов поверх OTP, которая предоставляет почти абсолютную fault-tolerance.
HL? — Ну как бы да. HE? — надежнее ничего не придумали пока, плюс hot uploads, которые вообще позволяют до неузнаваемости изменить исполняемый код без остановки системы.
Но нет, давайте продолжим мусолить искусственный вопрос: нода, или вордпресс?
В комментариях верно упомянули про Erlang и странную классификацию по которой Java и C# стали языками с динамической типизацией, а PHP противопоставляется WordPress (на котором он написан).
От себя хочу добавить вот что. Я понимаю, что у разработчиков на динамических языках все обложено тестами, но в качестве плюса динамической типизации упоминать антихрупкость, хотя очевидно, что дополнительные проверки типов как минимум не увеличивают вероятность ошибок, это по моему пропаганда уровня «война — это мир».
От себя хочу добавить вот что. Я понимаю, что у разработчиков на динамических языках все обложено тестами, но в качестве плюса динамической типизации упоминать антихрупкость, хотя очевидно, что дополнительные проверки типов как минимум не увеличивают вероятность ошибок, это по моему пропаганда уровня «война — это мир».
Не совсем. Динамическая типизация это сторона расширяемых систем, которая дает плюсы. Но не обязательна. Да, если писать расширяемую систему на Java & C# то динамические штуки там делать сложнее. В пхп проще. Вот и все.
Опять же сама по себе динамическая типизация не дает хрупкости. Выше в комментах где то писал. Гораздо важнее это модульность и сообщения. Просто когда делаешь модули и глубоко уходишь в сообщения, то рано или поздно приходишь к тому что от динамической типизации там получаешь больше преимуществ и гибкости. Меньше проблем с поздним связыванием и взаимодействием между модулями через сообщения. Но если очень хочется использовать статическую типизацию — то это тоже возможно.
Опять же сама по себе динамическая типизация не дает хрупкости. Выше в комментах где то писал. Гораздо важнее это модульность и сообщения. Просто когда делаешь модули и глубоко уходишь в сообщения, то рано или поздно приходишь к тому что от динамической типизации там получаешь больше преимуществ и гибкости. Меньше проблем с поздним связыванием и взаимодействием между модулями через сообщения. Но если очень хочется использовать статическую типизацию — то это тоже возможно.
если писать расширяемую систему на Java & C# то динамические штуки там делать сложнее
Внезапно, Хадуп написан на джаве, а что-то более динамическое, чем абстрактный мап-редьюс даже и вообразить-то сложно.
Просто когда делаешь модули и глубоко уходишь в сообщения, то рано или поздно приходишь к тому что от динамической типизации там получаешь больше преимуществ и гибкости.
Я не знаю, что такое «глубоко уходить в сообщения», я за мир без наркотиков, но это утверждение, как минимум, требует каких-нибудь примеров, что ли. Потому что доказательств у него нет, да и быть не может.
Ну примеры приведены в статье. Лишь малая часть тех что я встречал.
Системы на сообщениях — это когда модули общаются друг с другом и меняют поведение друг друга через сообщения.
В разных системах обмен сообщениям может быть построен через разные механики — события, хуки, триггеры.
Те примеры что приведены в статье — это малая часть, но там все именно так.
Системы на сообщениях — это когда модули общаются друг с другом и меняют поведение друг друга через сообщения.
В разных системах обмен сообщениям может быть построен через разные механики — события, хуки, триггеры.
Те примеры что приведены в статье — это малая часть, но там все именно так.
Ничто не мешает иметь модульность и сообщения со статической типизацией. Надежность системы это вопрос архитектуры прежде всего, а язык здесь играет роль второго плана. При этом я понимаю аргумент, что язык со статической типизацией и мощной системой типов в теории позволяет создать более надежный и менее хрупкий код, который сложнее сломать случайной правкой. При этом есть контраргумент, что статическая типизация расслабляет разработчиков и они реже пишут тесты. Здесь есть о чем спорить. Но заявлять что динамический язык повысит надежность системы это просто странно.
> Ничто не мешает иметь модульность и сообщения со статической типизацией
Согласен.
> При этом есть контраргумент, что статическая типизация расслабляет разработчиков и они реже пишут тесты. Здесь есть о чем спорить. Но заявлять что динамический язык повысит надежность системы это просто странно.
Тут важно отличать надежность от антихрупкости. Для этого нужно прочитать книгу. Объяснить это коротко боюсь не получится.
Плюс после этого поработать с большими и сложными системами построенными на статической типизации и на модулях с сообщениями и динамической типизацией. Сравнить их.
Согласен.
> При этом есть контраргумент, что статическая типизация расслабляет разработчиков и они реже пишут тесты. Здесь есть о чем спорить. Но заявлять что динамический язык повысит надежность системы это просто странно.
Тут важно отличать надежность от антихрупкости. Для этого нужно прочитать книгу. Объяснить это коротко боюсь не получится.
Плюс после этого поработать с большими и сложными системами построенными на статической типизации и на модулях с сообщениями и динамической типизацией. Сравнить их.
Но заявлять что динамический язык повысит надежность системы это просто странно.
Не надежность повысит, а уменьшит хрупкость. Грубо говоря, меньше кода нужно писать при изменении требований или появления новых.
Не знаю, кто такие Deno и Swoole.
Но, почему скриптовые языки PHP и NodeJS причисленны к имеющим «скорость исполнения»?!
C#, который не отнесли к имеющим «скорость исполнения», по-любому будет их на порядок быстрее, поскольку он компилируемый, а они — нет.
Но, почему скриптовые языки PHP и NodeJS причисленны к имеющим «скорость исполнения»?!
C#, который не отнесли к имеющим «скорость исполнения», по-любому будет их на порядок быстрее, поскольку он компилируемый, а они — нет.
Изучите что такое php Swoole.
На счет C# я готов поверить что он будет быстрее. Но только в виртуальном мире.
В реальном мире все сложнее. Там много чего и чаще всего качество кода.
Если хорошо писать код, то они все быстрые.
В реальном мире — все зависит от программистов. И тут вопрос культуры конкретной команды и уровня специалистов.
На счет C# я готов поверить что он будет быстрее. Но только в виртуальном мире.
В реальном мире все сложнее. Там много чего и чаще всего качество кода.
Если хорошо писать код, то они все быстрые.
В реальном мире — все зависит от программистов. И тут вопрос культуры конкретной команды и уровня специалистов.
Разве C#, как и Java не компилируется в байт-код, который потом интерпретируется виртуальной машиной by design?
Потому я удивился, что C# сочли «медленным».
Так PHP делает то же самое. Про JS не уверен, но в v8 (js-движок от Гугла) вообще JIT под капотом, как у Java и, наверное, C#. В PHP тоже можно сказать, что уже JIT под капотом. Так что на порядки далеко не факт, что зависит от типа языка, интерпретируемый или компилируемый.
Тем более, что сейчас вообще уже сложно формально провести границу между компилируемыми и интерпретируемыми языками — кучу оговорок надо делать, чтобы те или иные "априори" компилируемые или интерпретируемые языки не попали в неожиданную категорию.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
HighLoad vs HighExtensible — эффективность против антихрупкости