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

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

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

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

Почему так произошло? Потому что разные модели в голове у специалиста и клиента.

Как мог поступить специалист? Представить конструкторские расчеты предельно-допустимых износов и сопоставить их с реальными замерами. До тех пор, пока замеров нет, проблема не очевидна.

В голове роится: а вдруг разводят, а вдруг не справятся, ну ведь работает же...? Эти мысли не покидают его, даже если он согласился: а вдруг обманул, а может заменить его...?

Нагрузочное тестирование делает проблемы видимыми.

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

[UPDATE]: Говорят, что начинать проект с нагрузочного тестирования хорошо еще и тем, что можно хорошо погрузиться в структуру БД и публичных API сервисов.

Какая основная решаемая задача при создании фейкера объема данных?

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

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

Хорошо то, что в Python существует изобилие библиотек для работы со статистикой и с вероятностной распределенностью: numpy, pandas, scipy, statistics, да и стандартная библиотека random в Python поддерживают ряд актуальных функций.

Задача решается с помощью численных методов, используя «Аппроксимацию» и «Интерполяцию».

Допустим, у нас в таблице есть FK. Несложно получить список количества вхождений каждого значения, взять из этого списка несколько точек, вывести по ним функцию, которая будет использоваться для генерации данных. Впрочем, саму функцию можно не выводить, а ограничиться интерполяцией при генерации данных. Тогда вообще можно ограничиться стандартной функцией random.choices(...).

Поскольку это узкопрофильная область знаний, на которой я не специализируюсь, я прибегнул к помощи Евгения Козлова ( @ea_kozlov ), автора канала https://news.1rj.ru/str/careerunderhood

Конечно, нужно учитывать, что это не является гарантей идентичности планов запросов. Да и сам план на проде может измениться.

Если у вас имеется опыт или есть идеи по теме поста, с удовольствием выслушаю.

О спорах в профессиональных пабликах о том, существут ли деление на События/Команды, или между ними нет разницы, т.к. и то и другое - сообщение.

Даже условные операторы состоят из утверждений when и then.

Если говорить метафорически, то существует мнение, что нет никаких when и then, потому что они образуют единый условный оператор. Then не имеет смысла без When, а When - без Then.

Логично. Но все-таки, один и тот же Then может быть выполнен при различных When, что делает их различными. А при одном и том же When может быть выполнено несколько Then.

When/Then может быть на стороне сервиса-провайдера, и тогда сообщение несет Then, т.е. Команду. Может быть на стороне сервиса-потребителя, и тогда сообщение несет When, т.е. Событие (хореография, когда каждый сервис сам определяет свою роль в бизнес-процессе). А может быть между ними, т.е. ProcessManager.

Возвращаясь к вопросу о Командах/Событиях.

Команда является входящим портом доменной модели. Событие является результатом исполнения команды, т.е. исходящим портом. Говоря метафорически, Команда - это входные аргументы функции. Событие - это возвращаемое значение функцией.

Возникает вопрос - а где размещается логика, отвечающая за то, чтобы в ответ на Событие была инициирована необходимая Команда?

Ответ зависит от типа Relationship между Bounded Context (BC).

Допустим, заказ укомплектован и его нужно передать в доставку, т.е. доставить. Доставить груз/посылку. Обратите внимание на использование другого термина, которым утрачена избыточная определенность об оригинале, т.е. найдена новая абстракция, а значит, найдена новая модель с другим ubiquitous language.

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

Предположим, трансляция осуществляется в сервисе логистики, который подписан на Событие склада. Тогда это Anti-corruption Layer.

Или же она осуществляется в сервисе склада, т.е. в паблишере события. И в шину отправляется уже Команда, а не Событие. Тогда это Open Host Service, обычно с Published Language.

Реализуется слой трансляции, как правило, в виде адаптеров хексагональной архитектуры.

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

Обычно domain specific сервис осведомлен о generic сервисах. Но тут есть нюанс, который раскрывается в этой статье Nick Tune.

Коллеги, многие из вас знают Никиту Соболева, известного участника многих конференций, автора ряда широкоизвестных решений в области функционального программирования на Python.

У него есть канал, где он рассказывает про устройство VM Питона: https://news.1rj.ru/str/opensource_findings

Кстати, про архитектурные ката.
Еще один сборник ссылок описаний архитектуры решений победителей и призеров O'Reilly Software Architecture Katas можно посмотреть в ката-логе: https://github.com/TheKataLog

Недавно обсуждалось такое же явление в одном из профильных чатов. Как видно, это вовсе не редкость. Личный кабинет ИП налоговой службы РФ, форма подачи отчета движения средств по зарубежным счетам. Последний день подачи отчета.

Имел честь удостоиться быть упомянутым в книге, содержащей монументальный титанический труд. Книги такого уровня выходят в свет не чаще одного раза в десятилетие. О ней уже говорят на всех топовых мировых ИТ-конференциях. Книга о том, как создавать здоровые и успешные системы. Как я уже говорил, это даже не луч света в темном царстве спагетти-кода. Это настоящий прожектор путеводного маяка в океане архитектуры!

Эксперт по DDD пытается помочь команде тонущего проекта 🙂)

Признаться, раньше не слышал про https://mockintosh.io/ . Многим он подойдет лучше, чем Mountebank или WireMock, учитывая, что тестировщикам ближе Python. Правда, давненько коммитов уже не было.

Что используете вы для изоляции тестовой среды сервиса?

Вот такое народное творчество крупных ИТ-корпораций присылают мне в личку (публикуется с согласия собеседника).

Песнь про менеджера среднего звена:

В корпорации, среди стен,
Там, где свет не проникает совсем,
Жил был зверь, пугающий всех злобно,
Не конь-людоед, а глист-каннибал.

Он ползет, сверкают глаза,
Песня о нем страшна и грозна.
Видно, судьба у нас такова,
Бойтесь его, глиста-каннибала!

В корпорациях, среди стен,
Где умирает дух перемен,
Там, где таблицы скрывают пороки,
В правде своей мы одиноки

Не конь-людоед, а глист-каннибал,
Тихо ползёт, как ночь, как финал,
Сияют экраны, но пустота,
Власть здесь у тех, кто ест изнутра.

Корпорации строят из стали капканы,
Люди – просто энергия, планы.
А глист-каннибал, он не спит никогда,
Его миссия: жрать. Это навсегда.

И где-то в углу, в чёрной тени,
Горит монитор, мерцают огни.
Ты думаешь, выжил, но слышен сигнал:
"Иди ко мне, я глист-каннибал!"

Что я увидел здесь с управленческой точки зрения:

Где умирает дух перемен,

1. Отсутствие адаптации в модели разработки, т.е. итеративно-инкрементальная модель разработки не достигает своей цели. Это при том, что данная конкретная корпорация считает себя флагманом индустрии во внедрению Agile.

Там, где таблицы скрывают пороки,

Люди – просто энергия, планы.

2. Уклон в сторону проектных практик в ущерб продуктовым.

В правде своей мы одиноки

Власть здесь у тех, кто ест изнутра

3. Несбалансированное принятие технических решений, игнорирование интересов технической группы стейкхолдеров.

пугающий всех злобно

4. Прогрессирование страхов сторон разработки, т.е. цель Agile снова не достигнута (см. со слов "Software development is risky. People involved have many fears of what may go wrong" здесь).

Лично я отношусь к такому творчеству как к источнику ценной информации о наболевших системных проблемах.

Очень интересна неоднозначная реакция на предыдущие посты. Хотя описанное явление известно под названием "Larman's Laws of Organizational Behavior".

Gregor Hohpe описывал это в статье "Reversing the disablement cycle: Everyone does the right thing, yet nothing much gets done. How to break self-reinforcing bad habits."

И есть очень качественный русскоязычный ресурс по этой теме: "Что такое сопротивление изменениям и как с ним работать?"

На эту тему у меня была заметка о том, как осуществлять изменения в коллективе.

С днем рождения меня, дорогой! 🍾🎂🥂🎇🎊🎉
https://news.1rj.ru/str/emacsway/s/6