HighLoad vs HighExtensible — эффективность против антихрупкости

Давайте поговорим о high-load, high-extensible, ООП, DDD & EDA.


Речь пойдет о разнице между high load & high extensibility — это разные цели и задачи в разработке. Для которых нужны принципиально разные подходы. Которые часто вызывают когнитивный диссонанс среди программистов, предвещающий бурную полемику.


На Хабре много статей про high-load, а вот тема high-extensible как-то упускается из внимания.


Если попытаться примерно представить разность в понятиях и механиках, то вот табличка:


image


Давайте попробуем разобрать это все подробнее.


Хайлоад это хайлоад. Это быстрые ответы на запросы и постоянные соединения. Обычно тут php RoadRunner или Go или Rust, с асинхронностью и event loop. Проблема 10k и т. д.


ООП было придумано как решение задачи расширения или High Extensible. Тут лучше работают модульная разработка (MP, DDD) & обмен сообщениями (EDA, event driven architecture).


Мотивация


Суть проблемы, которая рассматривается в контексте этой статьи, заключается в том как команды работают с большими системами.


Речь идет о системах где разработку ведут 5-10 или больше команд, в каждой по 5-10 разработчиков.


Если просто в лоб решать задачи, то можно налететь на проблемы, которые описываются так:


  • команды начинают конфликтовать в GIT, мешать друг другу, ломать систему, увеличивается рост ошибок
  • переиспользование кода затрудняется, часть команд начинает дублировать работу друг друга
  • затрудняются релизы, увеличивается тайм-ту-маркет
  • сложнее прогнозировать сроки
  • множатся зависимости по задачам и блокеры, так как надо долго ждать результатов от смежных команд

Все это можно решить, или существенно снизить проблемы, если грамотно применять модули (MP), иногда домены (DDD) & обмен сообщениями (EDA как вариант), делая архитектуру более антихрупкой.


Быть эффективным или быть антихрупким?


Это две крайности одной и той же сущности.


В книге Антихрупкость, автор Нассим Талеб пишет о том что погоня за эффективностью всегда влечет рост хрупкости. Если мы ставим себе цель делать систему антихрупкой, нам придется жертвовать эффективностью. Иного не дано.


Антихрупкость любит случайность и неопределенность, что означает — и это ключевое свойство антихрупкости — любовь к ошибкам, к определенному классу ошибок. Уникальность антихрупкости состоит в том, что она позволяет работать с неизвестностью, делать что-то в условиях, когда отсутствует понимание, что именно делается, — и добиваться успеха.

Вам нужна система которая будет эффективной или антихрупкой?


Ответ на этот вопрос влияет на решения о том какие технологии следует использовать.


ООП было придумано как решение проблем расширяемости больших систем (большой функционал)


Цитата Алана Кея, автора ООП:


«Я придумал термин «объектно-ориентированный», и могу сказать, что я не имел в виду С++». Алан Кэй, конференция OOPSLA, 1997.

Ключ к созданию хороших масштабируемых систем это проработка механизмов общения модулей, а не проработка их внутренних свойств и поведения.

Я не против типов, но мне не знакома ни одна система типов, которая не вызывала бы боли. Так что мне все еще нравится динамическая типизация.

Позднее связывание позволяет с меньшими усилиями встраивать в проект идеи, которые возникли позже в процессе разработки (по сравнению с системами с более ранним связыванием вроде C, C++, Java, и пр.)

Я считал объекты чем-то вроде модулей, биологических клеток, и/или отдельных компьютеров в сети, которые могут общаться только через сообщения.

Я сожалею о том, что давным-давно придумал термин «объекты» для этого явления, так как его использование приводит к тому, что многие люди уделяют основное значение идее, которая не так важна, как основная. Основная идея — это обмен сообщениями

ООП для меня означает лишь обмен сообщениями, локальное сохранение, и защита, и скрытие состояния, и крайне позднее связывание

Итак, если взять эти идеи, то тезисами это можно сделать так:


  1. Масштабируемые и расширяемые системы состоят из модулей
  2. Модули общаются друг с другом через сообщения
  3. Это обеспечивает позднее связывание — крайне позднее связывание — код и логику можно менять в любой момент не меняя уже существующий код в модулях
  4. Для работы такой системы важна динамическая типизация, а не статическая

В 80е годы ООП разбилось на 2 типа


В книге Мифический человеко-месяц, автор Фредерик Брукс описывает момент когда ООП разбилось на 2 мира. Часть "Объектно-ориентированное программирование: а медна пуля не
подойдет?"


Разработка из больших частей. Если осуществлять сборку из частей, которые достаточно сложны и имеют однородные интерфейсы, можно быстро образовывать довольно богатые структуры.
Согласно одному из взглядов на объектно-ориентированное программирование эта дисциплина осуществляет модульность и чистые интерфейсы. Другая точка зрения подчеркивает инкапсуляцию — невозможность увидеть и еще менее изменить внутреннюю структуру детали. Еще одна точка зрения отмечает наследование и сопутствующую ему иерархическую структуру классов с виртуальными функциями. И
еще один взгляд: важнейшей является сильная абстрактная типизация данных вместе с гарантиями, что конкретный тип данных будет обрабатываться только применимыми к нему операциями.
В настоящее время не нужен весь пакет Smalltalk или C++, чтобы использовать любой из этих дисциплин — многие из них поглотили объектно-ориентированные технологии. Объектно-ориентированный подход привлекателен, как поливитамины: одним махом (т.е. переподготовкой программиста) получаешь все. Очень многообещающая концепция.

Получается что идея ООП зародилась в 60е годы, в 80е годы уже были разные точки зрения на то что есть ООП.


Сегодня под ООП чаще всего имеют ввиду классы. Хотя Алан Кей и Дэвид Уэст говорят что это ошибка. И что классы это всего лишь структуры данных. Это не про ООП. C++ & Java в базе не имеют ничего общего с ООП.


Речь идет про то ООП которое про модули и обмен сообщениями. Сегодня эта идеология чаще всего встречается в контексте модулей и сообщений или событий (EDA). Ты пишешь модули, которые обмениваются сообщениями через чистые интерфейсы (события, хуки, триггеры) с крайне поздним связыванием.


Так кто прав, а кто лев?


Если вам нужен HighLoad, вам надо топить за эффективность, масштабирование скорости исполнения, статическую типизацию, асинхронность, события и eventloop.


Если вам нужен HighExtensible, вам надо топить за антихрупкость, масштабирование скорости изменений, динамическую типизацию, модули и домены (DDD) и события как EDA (обмен сообщениями между модулями).


Причины проблем


Проблема в том что программисты спорят о том что ООП плохо (классы это медленно и хрупко, а функции быстро и круто, ну или как то там наоборот), о том что вот в PHP не хватает асинхронности и event loop.


Например эти темы поднимались на недавнем митапе SkyEng https://www.youtube.com/watch?v=QrlWrFILjMk


Но не понимают что это разговор о разных идеологиях, парадигмах и архитектурах. Это все равно что говорить что у дома нет колес или у автомобиля не хватает 3го этажа с ковром. Вот бы ложка была вилкой или вилка была бы ложкой. Вообще есть конечно вилка-ложки, но часто ли мы ими пользуемся вне горных походов?


Если вы создаете прикладную бизнес систему, где есть куча реальных пользователей, бизнес требования, бизнес аналитики, никто не знает что хочет, а требования меняются каждый день — вы очень сильно попадете в засаду если пойдете по пути HighLoad, будете делать статическую типизацию, асинхронность, без доменов и событий — вам будет больно. Тут нужно двигаться ближе к архитектуре для HighExtensible.


Если вы создаете микросервисы, которым надо отрабатывать 100 000 операций в секунду, то попытка пойти по пути динамической типизации, доменам, без асинхронности — тоже сделает очень больно. Тут стоит копать в сторону архитектуры под HighLoad.


Сделать одновременно HighLoad & HighExtensible — не реально или очень близко к не реальному. Попытки совместить эти две идеологии приводят к диким проблемам, большим затратам и часто к провалу.


Ну а программисты готовы спорить об этом до посинения. Не понимая что говорят про разные контексты, задачи и механизмы проектирования архитектур.


Примеры


Про high-load:


  • NodeJS — пошел с вектором в event loop & асинхронные механики. Есть много интересных кейсов с построением highload микросервисов и REST API.
  • Туда же можно отнести Go, Rust и разные механики PHP типа RoadRunner и PHP Swoole.

Про high-extensible


  • Можем взять Redmine, это типа система управления задачами, на базе RoR, там также есть модули (плагины), а общение модулей и обмен сообщениями строится на хуках;
  • Django использует концепцию Сигналов, которая по своей сути также является разновидностью обмена сообщениями между модулями или EDA;
  • Ребята из FreeScout решили делать систему хелпдеск на Laravel. Это прикладная система с кучей бизнес логики. Они реализовали свою архитектуру модулей (DDD) и обмена сообщениями (EDA) применив Eventy;
  • Eventy в свою очередь взял идею хуков из WordPress. Надо ли представлять этого зверя? Который держит более 30% рынка веб сайтов. Его архитектура также базируется на идеи модулей (плагинов, DDD), которые взаимодействуют друг с другом через сообщения (хуки, EDA).

Очень интересный опыт у ребят из iSpring:


https://www.youtube.com/watch?v=xT25xiKqPcI


Там речь о том чем отличается монолит от копролита. О том что если уметь готовить монолит, с DDD & EDA, то можно получить много преимуществ. А если не уметь — то и микросервисы не факт что помогут.


В общем, ребята ступили на путь освоения DDD & EDA. И это радует.


Заключение


Мир технологий в целом и разработок в частности очень многогранен. Если есть какая то технология — значит на то есть причины. Не знание этих причин еще не значит что технология плохая сама по себе.


Динамическая и статическая типизация — обе правильные, если их применять в соответствующих задачах.


ООП тоже очень разное может быть и есть много разных точек зрения на то что это такое. И все они правильные. Просто там разные контексты.


Вилка или ложка — не плохие и не хорошие. И если человек ест спагетти ложкой, а суп вилкой, а потом пишет о том что ложка это плохо, потому что спагетти вываливаются, и вилка плохо потому что суп хлебать ей не удобно — то разве это проблема в вилке или ложке?


Ну и под конец, хочется больше примеров. Кто какие еще примеры знает грамотного применения модулей и сообщений (DDD & EDA)?


Особенно интересует опыт построения HighExtensible систем в РФ. Потому что на западе его хватает. А тема high-load на Хабре и так перегрета. Хочется больше поговорить о практиках high-extensible.

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 55

    +10

    Т.е. в HighLoad вы записали Node.JS (который не прямо таки супер быстрый) и Deno, который вышел буквально недавно (и о котором Раян говорил что они только пытаются догнать Node.JS). Зато C# которые работает быстрее (в общем случае), поддерживает многопоточость (и асинхроннсть) из коробки у вас оказался на "другой стороне барикад".


    Почему?

      +4
      Ага, о том же хотел написать. HE это динамическая типизация (см. табличку), но в нее попали C# с Java. А вот HL статическая, но зато PHP, NodeJs. Классику жанра в виде С и C++ вообще забыли, хотя метод «переписать модуль на С» — это, как правило, достаточно радикальное решение боттлнеков. Ну и обмен сообщениями попал в HE… ну такое. В HL использовать кафку вполне себе вариант, чтобы сгладить пиковые нагрузки, и при этом расбросать поток на пул обработчиков.
        0
        Обмен сообщениями через кафку это скорее про очереди и многопоточность.
        Обмен сообщениями через хуки, события и триггеры это другая механика.
        Есть конечно и смешанные истории. Например мессенджер в симфони можно применять для построения обоих механик. Но это в теории. Хороших и интересных примеров построения EDA как механизма взаимодействия модулей через эту штуку я не встречал. Например уровня зрелости как из примера с фрискаут и эвенти.
          –1
          Динамическая и статическая типизация тоже очень условное и примерное деление.
          Я за статическую типизацию в части ХЛ, потому что там меньше риск утечки памяти и по моим наблюдениям такие решения работают эффективнее и быстрее.
          Однако разделяю точку зрения Алана Кея о том что это больно и что динамическая типизация в системах сложной бизнес логики даёт больше гибкости, антихрупкости.

          То что какие то языки поддерживают или не поддерживают это второстепенно. Зачастую почти везде можно выбирать как писать код. Но даже если нельзя то это не самое страшное. И не самое важное.

          Ключевое там это домены и события. Просто если в дополнение к ним можно уйти от жёстких типов это даёт плюс к гибкости. Этот момент также отметила докладчик из видео про опыт ispring.
          +1
          Ну и, тут можно оценить некую общую картину. В топ5 C++, Rust, Java, C#
            –2
            Мысль о том что C# .net, Java spring, php symfony часто используют для создания расширяемых систем взял из своего опыта и тех мыслей что озвучили ребята на митапе skyeng, ссылка в статье.

            Другая сторона баррикад это лишь условность. Популярность применения технологии для соответствующей практики.

            Конечно есть хайлоад микросервисы на си шарп, яве или симфони.
            Конечно есть попытки делать интернет магазины на nodejs.

            Но мой опыт и мои ощущения говорят о том что часто это походит на попытку чесать ногой за ухом. Можно, но больно и не удобно.

            Если же бизнес систему, панель управления, делают на Симфони, а какие то хайлоад запросы переводят на go, nodejs, или php roadrunner, то получается лучше.

            Опять же это лишь мои наблюдения из моего опыта. Они могу не отражать всей реальности. Может быть много исключений.

            Если будут какие то обратные примеры из реального опыта, то будет интересно узнать о них.
              +6

              Примеры по производительности вам уже привели выше.


              Что касается статьи — мысль хорошая, тема интересная. Но вы, простите, смешали мягкое с жидким причем в чувствительных местах. Node.JS замечательно расширяется (именно благодаря динамичности языка). С# замечательно быстр (в .NET Core 3.0 уделили много вниманмия производительности + со второй версии появились дополнительные низкоуровненвые способы оптимизации (Span, например).

              Возможно, статью стоит или переосмыслить или поменять акценты на собственный опыт.

                –1
                Нода замечательно расширяется. Сишарп быстрый.
                У меня нет возражений к этому.

                Вообще расширяемую систему можно построить на любом языке. Как и сделать быстрый хайлоад микросервис.

                В таблице я привёл своё видение и свои наблюдения о том что чаще в какой практик используется.

                Это не значит что нельзя делать иначе. Можно. Если осторожно.

                Однако в моей практие были печальные истории когда попытки сделать интернет магазин на ноде приводили очень к большим затратам и провалу проекта. Хотя по соседству такая же команда с такой же задачей на пхп двигалась сильно быстрее.

                Плюс изучение практик и рынка показывает что модульные и расширяемые системы чаще живут на пхп. На ноде тоже конечно есть примеры, но их меньше и они проще по функционалу.

                Сишарп не беру тк на нем мало примеров в опенсорсе. И я не силен в нём. Но сомневаюсь что он как то сильно отличается от пхп в данном контексте.
            +2
            Динамическая типизация — это антихрупкость? Как так вышло?
              –3
              Я не в курсе )

              Если взять только динамическую типизацию в вакууме то она мало на что влияет. И скорее всего никак не связана с антихрупкостью.

              В статье речь об обратном. о том чтобы построить антихрупкую систему, то надо копать в сторону DDD & EDA. Это основа.

              И вот там те кто проходят этот этап начинают отмечать что динамическая типизация удобнее и проще. Это отмечает Алан Кей, Дэвид Уэст, и тот же момент отмечается на видео про iSpring. Я тоже к этому выводу пришел.

              Но если больно об этом думать, то можно и на статической. Однако в полной мере это получится сравнить когда получится поработать с системами которые глубоко используют DDD & EDA. Сравнить большие системы с динамической и статической типизацией в реальных боевых условиях.
                +1
                построить антихрупкую систему, то надо копать в сторону DDD

                Видел упоротых по DDD людей, которые невероятно гордились тем, что для каждой сущности создавали доменный объект (для отработки бизнес логики), суррогат (для сериализации и десериализации из json для хранения в MongoDB), модель (для передачи по сети), конверторы (суррогат <-> объект <-> модель). Разумеется, работа с базой шла исключительно через репозиторий (отдельный для каждой сущности). Чтобы сделать минимальную операцию бизнес-логики, необходимо было извлечь json всех необходимых объектов из БД, десериализовать их в суррогат, преоразовать суррогат в объект, и вызвать метод. Также у них был документ в конфлюэнсе под названием ubiquitous language, где были бережно выписаны все сущности реального мира, которые участвуют в бизнес процессе.

                И вот, видя это все, могу с полной уверенностью утверждать, что антихрупкость не про это. Потому, что подобная система настолько заточена под конкрентный, закладываемый при написании, бизнес-процесс, что проявляет абсолютную беспомощность, когда вдруг надо реализовать прорывную, никак не предусматриваемую изначальным процессом, идею.

                А вот системы, которые опираются на SQL хранилища, напротив, демонстрируют невороятную антихрупкость, ведь позволяют в один запрос извлекать невообразимые ранее свойства системы, позволяя конструировать новые сущности, до которых не додумывались в реальном бизнес-процессе, на лету.

                Поэтому, лично для себя я сделал вывод, что DDD, — это, как поддержки для велосипеда. Он не позволит трейни и джунам написать полную дичь (которая запросто пишется при data-centric подходе, например), и при этом позволяет таким же новым трейни быстро понять шаблон. Но при этом, ни об эффективности, ни об антихрупкости говорить не приходится. Точно так же, как и странно на велосипеде с поддержками ставить рекорды на велотреке.
                  +3
                  > Видел упоротых по DDD людей, которые невероятно гордились тем, что для каждой сущности создавали доменный объект

                  Да, упоротые люди есть везде ) И я тоже видел много историй про DDD которые были очень далеки от реальности. От которых было проблем больше чем пользы.

                  Тоже самое можно сказать про типы, микросервисы, докеры, эджайл, скрам и т. д.

                  Абсолютно любой инструмент можно использовать так чтобы прострелить себе ноги и убить проект.

                  Наличие гитары в руках, даже если она самая лучшая в мире — не гарантирует что получится крутая музыка.

                  Потому тут речь идет о тех кейсах, где есть интересный и успешный опыт.

                  Я свои примеры привел. Те что мне понравились. И за которыми я наблюдаю.

                  Если есть крутые примеры — будет интересно узнать.

                  Если речь о том что где то плохо, и где то живут дураки — ну ок. Бывает. Зачем это изучать и на это тратить время?
                    0
                    Я свои примеры привел. Те что мне понравились.

                    Точно ли это DDD? Архитектуры с плагинами (в основном в десктоп приложениях для продвинутых юзеров) были распространены задолго до того, как DDD стал мейнстримом. К примеру, Far Manager. Сомневаюсь, что если открыть классику жанра вроде DDD Эрика Эванса и исходники подобного софта, то выйдет найти много общего.
                    Если же вы интуитивно вкладываете в понятие DDD инкапсуляцию, модульность и здравый смысл, то, наверное, стоит это называть это по-своему.
                    Наличие гитары в руках, даже если она самая лучшая в мире — не гарантирует что получится крутая музыка.

                    Развивая эту аналогию, я привел в пример не просто ребят, которые не умеют играть, а которые досконально выучили теорию, отработали сотни часов тренировок на гитаре, сдали экзамены в музыкальной школе на отлично, но вот все равно выходит какофония. Может все же в этом случае что-то с гитарой не так?
                      0
                      В программировании вообще мало чего точного. Все очень спорно :)

                      Я не готов говорить за кого то и за чье то понимание DDD.

                      Конкретно в контексте статьи мне понравился доклад iSpring. Они говорят что это DDD. Разбитие функционала на модули и общение модулей через события.

                      Эти же качества я вижу в Фрискаут, в Редмайн, в WHMCS и многих других продуктах.

                      Для меня DDD это разбиение системы на модули, которые обмениваются друг с другом через сообщения EDA (события, триггеры, хуки). Возможно есть какие то еще вариации, но мне достаточно этого для решения тех проблем, которые встречаю в разработке.

                      Может быть конечно что то не так с гитарой и DDD. Это не идеальный инструмент и в нем тоже есть куча проблем. Также есть много команд и задач, где это не подходящий инструмент. Я не говорю о том что всем надо это использовать.

                      Речь конкретно о HighExtensible системах, где важно обеспечивать взаимодействие модулей, команд, переиспользовать код, перестать толкаться локтями и конфликтовать в GIT. В этих кейса DDD при правильном применении очень сильно помогают.

                      Опять же мне понравилась мысль в опыте iSpring о том что важно чертить границы доменов правильно. Ошибка в границах домена — приведет к проблемам.

                      В общем в этом мире не все всегда и везде, а кое что иногда и местами :)
                        +3
                        Для меня DDD это разбиение системы на модули, которые обмениваются друг с другом через сообщения EDA (события, триггеры, хуки).

                        Это очень удобно, брать аббривеатуру и придумывать свои определения, «я художник, я так вижу». Мы так ни о чем не договоримся, максимум приятно пофлудим.


                        DDD у Эванса описано и это точно не то, что вы говорите. Идея разбить систему на модули и обмениваться сообщениями была ещё в 60х в SmallTalk.

                          0
                          Я не готов говорить за понимание Эванса. Также не готов говорить про SmallTalk. Потому что это все далеко и где то в другом мире.

                          Я предпочитаю говорить о практиках, которые можно пощупать, почитать код, проверить как это летает в реальной жизни. Иначе можно легко уйти в дебри теорий, заблудиться в фракталах терминологии.

                          Например мне в свое время понравилась эта статья dev.to/kmruiz/to-domain-driven-design-6ao — согласен с автором. Перекликается с моим опытом.

                          Но даже эта статья далека, и сложно проверить на сколько хорошо работают идеи и решают ли они обозначенную проблематику?

                          А вот видео ребят из скайэнга прям очень супер крутое www.youtube.com/watch?v=xT25xiKqPcI

                          То как там понимается DDD & EDA — также перекликается с моим пониманием. Плюс решает именно те проблемы, над которым у меня сейчас болит голова.

                          Если я художник и я так вижу, а также то же видят другие художники, у которых есть реальный практический опыт решения этих проблем — ну ок.

                          Если нужно говорить об Эвансе, то хочется начать с примеров как и где эти идеи помогли решить обозначенные проблемы?
                            +1
                            Ору. Вы вообще понимаете, что DDD — термин, введенный Эвансом?
                            Любое другое понимание этого термина — это лишь попытка примазаться к известному термину.

                            Зачем вы используете термины, которых не понимаете?
                              0
                              Не, не знал что он придумал термин.

                              Но видел ряд статей и видео о опыте реализации DDD по его книге. Мне не зашло.

                              Однако опыт с видео айспринг мне зашёл. И там речь тоже о DDD…

                              Вообще мне кажется что не бывает одного правильного подхода. Это скорее некая идеология и набор шаблонов. А в процессе реализации оно может принимать огромное количество форм и вариаций.

                              Потому я скорее предпочитаю изучать и размышлять о конкретной вариации которая ближе всего к моим проблемам и стеку. Например вариант реализации в айспринг.

                              Если он будет в чём то противоречить идеям Эванса, то я все равно предпочту опираться на него.

                              Пока не увижу опыт аналогичного качества который будет ближе к Эвансу.

                              Вот как то так )
                                +2
                                Да по барабану, нравится ли вам DDD в понимании Эванса или нет. Вы или называете вещи своими именами или просто примазываетесь к термину. И то, что разработчики из iSpring возможно неправильно применяют этот термин — вам оправдания не делает.

                                Уже чисто по тому, как вы выворачиваете вопрос правильного именования становится ясно, что ваше DDD и близко к термину не относится. Ну кроме разве что некоторого набора практик, чисто внешнеё сходство и все.

                                Вообще мне кажется что не бывает одного правильного подхода. Это скорее некая идеология и набор шаблонов. А в процессе реализации оно может принимать огромное количество форм и вариаций.

                                Вопрос не в том, правильный подход или нет. Вопрос в терминах. Вы сможете без гугла ответить, в чем идеология DDD? Вы понимаете, что если {Something} Driven Development использует арифметические операторы, то это не делает арифметические операторы единственным определяющим аттрибутом {Something} Driven Development?
                                  0
                                  Да, похоже уловил мысль.

                                  Если это столь больно бьет по чувствам верующих, то попробую поменять термин DDD на модули.

                                  Это будет ближе к той мысли, которую озвучил Алан Кей, о том что расширяемые архитектуры базируются на модули, и надо думать не о модулях, а о том как модули взаимодействуют — обмен сообщениями.
                                    +1
                                    Также не готов говорить про SmallTalk.

                                    Это будет ближе к той мысли, которую озвучил Алан Кей, о том что расширяемые архитектуры базируются на модули, и надо думать не о модулях, а о том как модули взаимодействуют — обмен сообщениями.

                                    Эванса не знаем, но знаем DDD. SmallTalk не знаем, но о высказываниях создателя SmallTalk Алана Кея знаем, забавно :)

                                      0
                                      Да, вот так вот ))

                                      В общем поменял в статье акценты. Сделал больше упор на модульность. DDD это лишь одна из вариаций. Сама по себе имеет ценность, но далеко не везде.

                                      Сделал больше акцента на модульность и сообщения.

                                      На мой взгляд это именно то что нужно для расширяемых систем.

                                      SmallTalk нафиг. Он может быть и крут, но толку от этого если сегодня другой мир и другие понятия.

                                      Потому смотрим на что реально стреляет и применяется.
                                        +1
                                        SmallTalk нафиг. Он может быть и крут, но толку от этого если сегодня другой мир и другие понятия.

                                        Это где это сегодня другой мир? В комментариях к заметкам, сравнивающим ноду и похапе?


                                        Очень трудно объяснить вкус дыни человеку, который всю жизнь жевал сапожные шнурки. — Виктор Шкловский

                                        Понимаете, смешно слушать рассуждения про хайлоад и хрупкость от людей, которые никогда не сталкивались ни с тем, ни с другим (по крайней мере, на низком уровне). Взять кафку какую-нибудь — большого ума не надо, но хорошо бы при этом понимать, что это развитие идеи именно смолтолка.


                                        Вотсап не случайно работает на эрланге, а эрланг (другие времена, хех?) — тот же смолтолк, только отказоустойчивый. Да, в энтерпрайзе другие священные коровы, но девять девяток не всякая джава потянет, не говоря про дотнет.


                                        Так что «нафиг» отправлять прародителя всех систем, построенных на модели акторов — это очень странный подход. По крайней мере, в тексте, упоминающем HL и HA.

                            0
                            Идея разбить систему на модули и обмениваться сообщениями была ещё в 60х в SmallTalk.

                            Кей, конечно, тот еще старикан, но в шестидесятых он учил колорадских студентов играть джаз на гитаре, а потом — занимался FLEX. SmallTalk появился уже в семидесятых.


                            И не «на модули», а на «маленькие компьютерчики».


                            :)

                              0
                              Да, в древности он так и говорил. Про маленькие компьютеры. Тогда просто не было той путаницы что есть сегодня.

                              Но если брать его комменты из последних лет, то он уже пришел к мысли что речь была про модули и модульные системы )
                            +1
                            Конкретно в контексте статьи мне понравился доклад iSpring. Они говорят что это DDD. Разбитие функционала на модули и общение модулей через события.

                            Вы услышали то, что хотели услышать. Там не сказано, что EDA (события, триггеры, хуки) — это DDD. DDD допускает событийную архитектуру, но оно не про это. DDD допускает разделение на модули, но оно тоже не про это. DDD как раз, с технической точки зрения, про стопятьсот слоёв абстракций, обеспечивающих, как побочный эффект, антихрупкость несколькими путями:


                            • разделение всего кода на слои, у которых разные причины для изменений, прежде всего у доменного слоя одна причина — изменения в предметной области ну, или, изменения в представлении разработчиков о предметной области. Ни смена посгтреса на монгу, ни переход с ларавел на симфони, ни переход на событийную архитектуру с прямой связи, ни обратный не должны менять слой domain.
                            • разделение всего кода на ограниченные контексты, в которых у каждой моделируемой сущности предметной области, своя техническая модель (которая даже именоватьсяя может по разному и быть семантически разными вещами, например, в одном контексте сущность, а в другом — объект-значение) и контексты отделены друг от друга, общаются только через строго определённые контракты
                              0
                              Да, возможно.

                              В докладе айспринг мне понравилась мысль о том что после DDD образуется проблема EDA. Но не все доходят до этого. Далее идет акцент на EDA.

                              Потому вероятно лучше заменить термин DDD на модули.

                              Но у них много схожих и важных идей: важность определения границы доменов будет звучать как важность определения границ модулей.

                              Первопричина изменения модуля и домена тоже совпадают. Модули также базируются на идеи первопричины изменения. Но кроме того там еще есть цель делать модули по командам. Чтобы команда могла работать в границах 1 модуля.

                              В моем понимании это все схожие идеи и понятия. Но коли это вводит такую путаницу и резкую реакцию, то легче поменять термин, чем пытаться спорить )
                        +3

                        Я конечно не оправдываю overengineering, и три слоя объектов это реально перебор. Но вот ubiquitous language — действительно полезная штука. Особенно, когда она работает не только для разработчиков, но и для PM, тестеров, аналитиков. Потому что в противном случае появляется по два-три названия для одного и того же: одно в багтрекере, другое в документации, третье в коде.

                          0

                          DDD — это прежде всего о взаимодействии бизнеса и разработки. Сущности, репозитории и прочие доменные сервисы — это технические шаблоны, обязательны к применению. Обязательно чтобы код легко маппился на предметную область, а там хоть на ФП пиши вообще без объектов.

                    +3

                    Статья может быть и хорошая, но вы не понимаете, что такое антихрупкость и главный тезис в корне не верен.


                    Это из заголовка научной статьи Талеба по теме.


                    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) для эволюции. Эволюция перестала быть антихрупкой и развалилась. Зато стало очевидно, что антихрупкость относительна, а один и тот же объект может быть хрупким и антихрупким одновременно. И этот ещё одна проблема с тезисом — вы вставляете относительную величину в абсолютное высказывание об эффективности и антихрупкости.


                    Научпоп это роман, вы же не учитесь фехтовать по «Трём мушкетерам», так вот не надо учиться проектировать по художественным книгам. Учите матан и читайте оригиналы толковых статей.

                      0
                      для реализации небольшого требования

                      давайте запускать программу под DOS 1.0

                      А кто сказал, что это небольшое требование?
                        0

                        А это на самом деле не важно. Важно только то, что если требования колбасит, то программе от этого плохо. Антихрупкой программе от этого должно быть хорошо, хотя бы до определенного предела. Сравните это с эволюцией, если взять за метрику супремум IQ популяции, то изменения среды это необходимый компонент его увеличения.


                        Тут ещё пара шагов до того, чтобы саму идею «анитихрупкости» начать серьезно критиковать.

                        0
                        А можно мне показать где в статье антихрупкость возведена в абсолют?

                        Да, согласно автору, в антихрупкости есть такая штука, что не существует метрик и возможностей ее измерить.

                        Есть лишь возможность сравнивать 2 системы относительно 1 события и говорить о том какая из них более или менее хрупка относительного указанного события.

                        И в моей практике была такая возможность. Были 2 команды, которые делали магазин. Одна на пхп, с доменами и событиями. Вторая на ноде с асинхронностью. Первая двигалась очень быстро, быстро дошла до результата и показала очень крутые метрики прибыли. Вторая команда двигалась очень медленно, постоянно спотыкалась и в какой то момент проект пришлось закрыть, а команду уволить.

                        Проблемы были плюс минус те же самые — не ясность требований, частое изменение задач, слабые процессы постановки задач. Все это плохо влияло на продукты. Но вот хрупкий продукт умер, а антихрупкий — выжил и показал отличные результаты.

                        Компетенции команд тоже были плюс минус похожие. Команда с нодой регулярно говорила о том что пхп дно и что будущее за нодой ) Вот только реальность оказалась иной )
                          0
                          А можно мне показать где в статье антихрупкость возведена в абсолют?

                          Извиняюсь, если прозвучит немного грубо, но нужно читать, что написано, а не то, что вам хочется прочитать. Читать по буквам и внимательно, это непросто, но необходимо. Не возведение в абсолют, а «абсолютное высказывание». Это высказывание вида «для всех X (вообще) Y». А вот оно в статье

                          погоня за эффективностью всегда влечет рост хрупкости. Если мы ставим себе цель делать систему антихрупкой, нам придется жертвовать эффективностью. Иного не дано.

                          Другими словами «для всех систем (вообще) существует инвариант вида Хрупкость + Эффективность = const».

                          Да, согласно автору, в антихрупкости есть такая штука, что не существует метрик и возможностей ее измерить.

                          А здесь уже неверно прочитан текст Талеба. Вот скрин из него image

                          Выше есть значки, с их помощью можно делать непротиворечивые утверждения. Другой способ — показать многократно повторенный эксперимент, в контролируемой среде. Все остальное это размахивание руками, разной степени полезности. Крайне желательно понимать, когда делаются утверждения, а когда происходит размахивание руками.

                          Но вот хрупкий продукт умер, а антихрупкий — выжил и показал отличные результаты.

                          Я не знаю как вы «анитихрупкость» применили к «системе», если автор явно говорит, что все это про распределения вероятностей.
                            0
                            Да, может быть формулировка не очень.
                            Вот цитаты:
                            > Хрупкость и антихрупкость здесь – относительные понятия, а не абсолютные качества: объект, находящийся справа от точки отсчета, более антихрупок, чем объект, который находится слева.

                            > Как видит читатель, карта без каких-либо ограничений распространяется на любые области и сферы деятельности: культура, здравоохранение, биология, политические системы, технология, городское планирование, социально-экономическая жизнь и прочие явления

                            Если карта хрупкости и антихрупкости применяется к любым объектам, вещам и системам, включая политические системы и технологии, то почему я не могу ее применить для программной системы?

                            Ту же стратегию штанги отлично получается применять к покеру. Это вообще очень гибкая теория и ее применение возможно в самых разных областях.
                              0
                              Если карта хрупкости и антихрупкости применяется к любым объектам, вещам и системам, включая политические системы и технологии, то почему я не могу ее применить для программной системы?

                              Можете и это даже имеет некоторый смысл. Но вы не можете противопоставлять антихрупкость и эффективность, в том смысле, в котором вы о них говорите в статье.

                        0
                        В книге Антихрупкость, автор Нассим Талеб пишет о том что погоня за эффективностью всегда влечет рост хрупкости. Если мы ставим себе цель делать систему антихрупкой, нам придется жертвовать эффективностью. Иного не дано.

                        На какие только ухищрения слов и терминов не идут программисты, лишь бы донести владельцам бизнесов простую мысль, что за скорость всегда приходится платить качеством
                          0

                          Это враньё программистов, которым они прикрывают свою неопытность. Возьмите команду, которая уже 20 лет делает ERP и они вам сделают ERP быстро, качественно и дешевле чем аналогичная команда с опытом создания 3D игр.

                            0

                            Они же сделают ещё быстрее и дешевле, если сказать, что качества особого не надо.

                              0
                              Если я знаю как решать задачу, я решаю ее а) быстро б) качественно в) относительно дешево (без переделок, задержек, потерянной прибыли и т.п.) Если же я не знаю как решать задачу, то я экспериментирую и получается а) долго б) так-себе по качеству в) дорого, по многим причинам. Возможно, кто-то умеет по другому, но я такого не видел. Поэтому я считаю (сужу по себе), что в программировании либо качественно/быстро/дешево, либо так-себе/дорого/долго.

                              У команды ERP, о которой речь, качество заложено в их библиотеках, подходах и опыте. Это не то, что вы сможете променять на скорость.
                                0

                                Такие вещи как, например, написание тестов отнимают время и деьги, как не крути, но увеличивают, при правильном применении, качество. Я уж молчу про нормальную обработку ошибок, граничных случаев, и даже безопасность, на которые часто забивают, когда "сроки жмут"

                          +2
                          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, которые вообще позволяют до неузнаваемости изменить исполняемый код без остановки системы.


                          Но нет, давайте продолжим мусолить искусственный вопрос: нода, или вордпресс?

                            +1
                            В комментариях верно упомянули про Erlang и странную классификацию по которой Java и C# стали языками с динамической типизацией, а PHP противопоставляется WordPress (на котором он написан).
                            От себя хочу добавить вот что. Я понимаю, что у разработчиков на динамических языках все обложено тестами, но в качестве плюса динамической типизации упоминать антихрупкость, хотя очевидно, что дополнительные проверки типов как минимум не увеличивают вероятность ошибок, это по моему пропаганда уровня «война — это мир».
                              0
                              Не совсем. Динамическая типизация это сторона расширяемых систем, которая дает плюсы. Но не обязательна. Да, если писать расширяемую систему на Java & C# то динамические штуки там делать сложнее. В пхп проще. Вот и все.

                              Опять же сама по себе динамическая типизация не дает хрупкости. Выше в комментах где то писал. Гораздо важнее это модульность и сообщения. Просто когда делаешь модули и глубоко уходишь в сообщения, то рано или поздно приходишь к тому что от динамической типизации там получаешь больше преимуществ и гибкости. Меньше проблем с поздним связыванием и взаимодействием между модулями через сообщения. Но если очень хочется использовать статическую типизацию — то это тоже возможно.
                                0
                                если писать расширяемую систему на Java & C# то динамические штуки там делать сложнее

                                Внезапно, Хадуп написан на джаве, а что-то более динамическое, чем абстрактный мап-редьюс даже и вообразить-то сложно.


                                Просто когда делаешь модули и глубоко уходишь в сообщения, то рано или поздно приходишь к тому что от динамической типизации там получаешь больше преимуществ и гибкости.

                                Я не знаю, что такое «глубоко уходить в сообщения», я за мир без наркотиков, но это утверждение, как минимум, требует каких-нибудь примеров, что ли. Потому что доказательств у него нет, да и быть не может.

                                  0
                                  Ну примеры приведены в статье. Лишь малая часть тех что я встречал.

                                  Системы на сообщениях — это когда модули общаются друг с другом и меняют поведение друг друга через сообщения.

                                  В разных системах обмен сообщениям может быть построен через разные механики — события, хуки, триггеры.

                                  Те примеры что приведены в статье — это малая часть, но там все именно так.
                                    0
                                    В разных системах обмен сообщениям может быть построен через разные механики — события, хуки, триггеры.

                                    В популярных ООП языках отправка сообщения объекту — это вызов его метода :)

                                  0
                                  Ничто не мешает иметь модульность и сообщения со статической типизацией. Надежность системы это вопрос архитектуры прежде всего, а язык здесь играет роль второго плана. При этом я понимаю аргумент, что язык со статической типизацией и мощной системой типов в теории позволяет создать более надежный и менее хрупкий код, который сложнее сломать случайной правкой. При этом есть контраргумент, что статическая типизация расслабляет разработчиков и они реже пишут тесты. Здесь есть о чем спорить. Но заявлять что динамический язык повысит надежность системы это просто странно.
                                    0
                                    > Ничто не мешает иметь модульность и сообщения со статической типизацией

                                    Согласен.

                                    > При этом есть контраргумент, что статическая типизация расслабляет разработчиков и они реже пишут тесты. Здесь есть о чем спорить. Но заявлять что динамический язык повысит надежность системы это просто странно.

                                    Тут важно отличать надежность от антихрупкости. Для этого нужно прочитать книгу. Объяснить это коротко боюсь не получится.

                                    Плюс после этого поработать с большими и сложными системами построенными на статической типизации и на модулях с сообщениями и динамической типизацией. Сравнить их.
                                      0
                                      Но заявлять что динамический язык повысит надежность системы это просто странно.

                                      Не надежность повысит, а уменьшит хрупкость. Грубо говоря, меньше кода нужно писать при изменении требований или появления новых.

                                  0
                                  Не знаю, кто такие Deno и Swoole.
                                  Но, почему скриптовые языки PHP и NodeJS причисленны к имеющим «скорость исполнения»?!
                                  C#, который не отнесли к имеющим «скорость исполнения», по-любому будет их на порядок быстрее, поскольку он компилируемый, а они — нет.
                                    0
                                    Изучите что такое php Swoole.
                                    На счет C# я готов поверить что он будет быстрее. Но только в виртуальном мире.
                                    В реальном мире все сложнее. Там много чего и чаще всего качество кода.
                                    Если хорошо писать код, то они все быстрые.
                                    В реальном мире — все зависит от программистов. И тут вопрос культуры конкретной команды и уровня специалистов.
                                      0

                                      Разве C#, как и Java не компилируется в байт-код, который потом интерпретируется виртуальной машиной by design?

                                        0
                                        Потому я удивился, что C# сочли «медленным».
                                          0

                                          Так PHP делает то же самое. Про JS не уверен, но в v8 (js-движок от Гугла) вообще JIT под капотом, как у Java и, наверное, C#. В PHP тоже можно сказать, что уже JIT под капотом. Так что на порядки далеко не факт, что зависит от типа языка, интерпретируемый или компилируемый.


                                          Тем более, что сейчас вообще уже сложно формально провести границу между компилируемыми и интерпретируемыми языками — кучу оговорок надо делать, чтобы те или иные "априори" компилируемые или интерпретируемые языки не попали в неожиданную категорию.

                                    Only users with full accounts can post comments. Log in, please.