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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поскольку это узкопрофильная область знаний, на которой я не специализируюсь, я прибегнул к помощи Евгения Козлова ( @ea_kozlov ), автора канала https://www.tgoop.com/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://www.tgoop.com/opensource_findings

Презентация по одной хорошей книжке Влада Хононова (Vladikk).

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

3k подписчиков — спасибо!

У нас тут в группе задали хороший вопрос — какие документы создают БА, а какие — СА?

Мой заход в тему:

БА:
- диаграмма оргструктуры
- регламент бизнес-процесса
- модель бизнес-показателей
- карта процессов предприятия
- контекстная диаграмма процесса
- диаграмма потока создания ценности
- карта клиентского опыта
- модель бизнес-процессов
- модель предметной области
- отчет об обследовании
- аналитическая записка
- реестр бизнес-правил
- бизнес-требования
- требования заинтересованных лиц
- модель проблем и целей проекта
- бизнес-ограничения проекта
- концепция автоматизации
- технико-экономическое обоснование проекта / business case
- сценарии использования информационной системы уровня чёрного ящика
- техническое задание на выбор, заказ, разработку, построение информационной системы
- регламенты применения информационной системы
- макеты отчётов
- алгоритмы расчета бизнес-величин

СА (в автоматизации бизнеса и создании ИТ-продуктов):
- модель данных, словарь данных
- модели жизненного цикла объектов ИТ-системы
- функциональные требования к ИТ-системе
- карта пользовательских историй
- алгоритмы обработки данных
- атрибуты качества ИТ-системы
- расчеты количественных показателей эксплуатации ИТ-системы во времени
- модель надежности ИТ-системы
- технические ограничения ИТ-системы
- контекстная диаграмма ИТ-системы или подсистемы
- сценарии использования ит-системы уровня серого ящика
- предложения по функциональному и структурному разбиению ИТ-системы
- техническое задание на проектирование и разработку подсистемы
- структура БД
- сценарии интеграции системы
- спецификация API
- диаграмма навигации по экранам
- черновые макеты пользовательских интерфейсов
- технический проект на разработку ИТ-системы

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

Выступил вчера на AnalystDays'16. На этот раз постарался выдать максимум шаблонов и цепочек промптов, чтобы можно было сразу брать и применять. Держите презентацию!

Мы подготовили очередной раздел базы ссылок по инженерии информационных систем http://Systems.Wiki

На этот раз раздел по Инженерии Требований.

В него попали подборки ссылок по темам:

Общие стандарты и своды знаний

Сертификации

Международные журналы

Международные сообщества

Международные конференции

Общие пособия по разработке требований

Инструменты разработки и управления требованиями

Критика инженерии требований

Инженерия требований в машиностроении

Инженерия требований в авиации

Формулирование требований

Разработка бизнес-требований

Требования к продукту

Требования уровня пользователей
— User Stories
— User Story Mapping
— Use Cases

Разработка системных требований

Разработка требований к информационным системам

Разработка требований к ПО

Обеспечение полноты требований к ПО

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

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

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

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

Очень интересна неоднозначная реакция на предыдущие посты. Хотя описанное явление известно под названием "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."

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

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