Системный сдвиг

Я слежу за статьями Пола Ральфа (который писал про иллюзию требований), но эта ветка исследований немного заглохла. Зато есть свежая статья: "Влияние генеративного ИИ на креативность в разработке ПО".

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

Авторы определяют креативность как "Способность придумывать идеи или создавать артефакты, которые являются новыми, неожиданными и ценными".

Дальше они раскладывают креативность по модели 4P: Person, Product, Process и Press (давление окружения) и пытаются анализировать влияние генеративного ИИ с позиций тетрадного анализа Маршалла Маклюэна — это, напомню, один из самых влиятельных философов XX века, описавший современные медиа и их влияние на общество. Тетрада задает рамку анализа новой технологии — какие практики технология усиливает, какие делает устаревшими, какие наоборот возвращает из забытья, и к чему приводит в пределе? (По Маклюэну — к противоположности)

Вот что получилось.

Влияние на личную креативность:
Усиливает:
- Генерацию идей
- Объединение идей из разных областей
- Быструю проверку/отладку
- Тщательный подход
- Понимание стейкхолдеров
- Выбор подходящего варианта

Делает устаревшим и ненужным:
- Различие в личных качествах
- Глубокое мышление
- Рефлексию
- Экспертизу
- Менторинг

Возвращает:
- Эскизное проектирование, наброски
- Верификацию
- Творческую работу

Приводит к обратному:
- Штамповке типовых решений
- Исключению анализа вариантов
- Потере креативных навыков

Влияние на продукт:
Усиливает:
- Непрерывное улучшение
- Кастомизированный UX
- Учет обратной связи
- Возможность делать "невозможные вещи"
- Радикальные инновации

Делает устаревшим:
- Стандартные решения
- Фреймворки
- Промежуточные артефакты проектирования
- Графический дизайн и элементы оформления
- Специализированные артефакты (музыку, звуки, дизайн уровней, баз данных, интерфейсы и т.п.)

Возвращает:
- Паттерны и стили
- Старые приемы проектирования и решения
- "Аналоговые" методы проектирования — на карточках, на бумаге

Приводит к обратному:
- Эффекту "эхо-камеры": подтверждение предвзятости, ограничение вариантов
- Однообразные продукты
- Чрезмерно креативным, вычурным продуктам
- Предвзятости
- Вредным продуктам, черному UX, эксплуатации аддикций

Влияние на процессы:
Усиливает:
- Обыденные задачи
- Быстрое прототипирование
- Коллаборацию
- Креативность по запросу
- Модерацию/фасилитацию

Делает устаревшим:
- Мозговые штурмы
- Специализацию, разделение ролей
- Техники проверки дизайна (изучение пользователей, фокус-группы, мысленное пошаговое прохождение интерфейсов и т.п.)
- Экспертов по креативным методикам и проектированию

Возвращает (тут всё в противодействие):
- Парное программирование
- Техники генерации идей (мозговые штурмы, дизайн-спринты)
- Аналоговые техники творчества (лего, бумажное прототипирование и т.п.)
- Ручные исследования пользователей
- Изучение других предметных областей

Приводит к обратному:
- Потере интуиции
- Потере доверия
- Потере работы
- Разложению ролей специалистов по созданию ПО
- Кафкианской безответственности

Влияние на среду:
Усиливает:
- Поиск контекстной информации
- Вдохновение окружающей средой
- Сборку команд
- Эффективность в виртуальных средах
- Психологическую безопасность
- Голос разума
- Готовность принимать риски

Делает устаревшим:
- Доски, флипчарты, стикеры
- Кубиклы
- Фиксированные пространства
- Офисы вообще
- Коллег

Возвращает:
- Креативность в движении
- Поддерживающее руководство

Приводит к обратному:
- Саботажу
- Изоляции
- Снижении гордости за результаты своего труда
- Давлению руководства
- Невозможности высказаться
- Ненужности креативности

Ну что, как вам такие предположения?

С наступившим Новым годом!

В одном из новогодних обращений услышал: а ведь уже прошла четверть XXI века! Те, кто постарше (как я), помнят, что 21 век казался каким-то фантастическим. Ну он такой и есть! Вокруг нвс сплошная фантастика: у всех "персональные коммуникаторы", мы погружены в виртуальные миры, звоним с видео в любую точку мира, по улицам ездят роботы и машины без водителей, мы каждый день разговариваем с искусственным интеллектом, всерьёз собираемся колонизировать Луну и Марс, почти не используем наличные деньги, операции делают роботы и т.д. Фантастика!

Ну а для меня самый приятный символический подарок — достижение каналом 10k подписчиков, это круто!

Ну и традиционно — вам подарок от меня: пишите в комментариях о своих каналах, а я потом сделаю общий пост с упоминанием всех! Всем пишущим и снимающим — роста в этом году!

Нужно, наверное, какие-то итоги года подвести.

Итоги такие:
1. Канал немного не дотянул до 10 тыс.; число, конечно, символическое, но было бы приятно. В целом заметно замедление роста — то ли в алгоритмах рекомендаций что-то поменялось, то ли я стал писать про абстрактные вещи, не особо интересные. Оторвался от потребностей аудитории — а что, вполне возможно.

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

3. О чем писал:
* Сильно обновил карту интеграций: раз и два
* С какими видами неопределенности работает аналитик и что с ними делать?
* Экономическая обоснованность автоматизации задач
* Шпаргалка по структуре http-запроса (надо бы сделать всё-таки сборник "интеграции в картинках")
* Вытащил в наглядную таблицу пример стоимости масштабирования
* Перевел несколько комиксов про разработку
* Написал про формулу Пуассона для расчета нагрузки в интеграциях
* Немного поборолся с распространенными мифами: про снижение неопределенности к концу проекта (Cone of uncertainty) и про стоимость исправления ошибки в зависимости от стадии обнаружения
* Запостил "Пирамиду требований", которую обычно на тренингах рисую
* Написал про эмоциональный компонент JTBD
* И про "Ясный язык"
* Про неизбежность диктатора при принятии коллективных решений и преодоление этой неизбежности
* Провел небольшое исследование — про среду в компаниях по методу Ясвина
* Про радар выбора процесса разработки — подходит ли для вашего проекта Agile?
* Какие решения и в каком виде можно передавать ИИ?
* Нашел граф со всеми возможными нефункциональными требованиями
* А ещё — каталог паттернов миграции со старой системы на новую
* И шаблон для PRD
* Сходил на новые конференции от JUG.ru — BiasConf и InBetween
* Пошутил про приколы интеграции (не протоколы!)
* Подсмотрел, как живут продакты (по отчету Atlassian)
* Поучаствовал в проектировании и анализе исследования системных аналитиков
* Завел отдельный канал про цифровизацию образования
* Написал про "Дома качества" — методику связывания функциональных и нефункциональных свойств с конструктивными особенностями и продуктовыми метриками
* Затеял несколько постов про DDD
* И вообще про роли аналитика и архитектора: раз, два и три
* А также сделал чеклист для выявления микросервисов и написал про канвас для ограниченных контекстов

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

А вообще — много о чем за год удалось написать, хватает уже материала на книгу? "Современные методики анализа и проектирования систем"? Звучит, как учебник. Или "Записки аналитика"? ("у изголовья", подсказывает ассоциативная память).

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

С наступающим Новым годом!
🎄🎁🥂🎆

Статья Дуэйна Перри и Александра Вольфа 'Foundations for the Study of Software Architecture' 1992 года достойна отдельного поста. Это одна из самых цитируемых работ по программной инженерии за всю историю.

В ней много интересных тезисов. Например, что архитектура ПО больше всего похожа на архитектуру зданий: требует нескольких отдельных видов, отражающих разные аспекты одной системы (или здания); имеет выраженные архитектурные стили, определяющие используемые элементы и их возможные связи; при этом стили связаны с инженерными принципами (то, что ты строишь, зависит от того, как ты строишь) и с материалом (...и из чего ты строишь).

Дальше они характеризуют разные уровни рассмотрения:
— требования определяют информацию, процессы её обработки, а также характеристики этой информации и процессов обработки, требуемые пользователям;

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

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

— реализация связана с представлением алгоритмов и типов данных, которые удовлетворяют проекту, архитектуре и требованиям. (Видимо, "представлением в виде кода")

Тут авторы оговариваются, что не во всех системах нужны все уровни, и иногда можно просто начать программировать (например, в проектах с искусственным интеллектом — напомню, это 1992 год!)

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

Итак, авторы определяют архитектуру через три понятия:

Software Architecture = { Elements, Form, Rationale }

Элементы архитектуры делятся на три класса:
* элементы обработки
* элементы данных
* соединительные элементы

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

Наконец, неотъемлемой, самой важной частью архитектуры является обоснование различных решений, принятых при определении архитектуры. Обоснование отражает мотивацию выбора архитектурного стиля, выбора элементов, и формы. Таким образом, главный документ архитектуры — не схема соединений конкретной системы (это проект). Главный документ — описание базовых принципов и принятых решений, то есть ADR.

Собственно, архитектурный стиль — это некий набор готовых решений, которые умные люди уже сделали за вас. Две главные проблемы архитектуры проявляются при изменении систем: эрозия и дрейф. Эрозия — это нарушение принципов определенной архитектуры или выбранного архитектурного стиля, а дрейф — когда сами принципы уже невозможно определить.

Интересно, как они определяют свойства — как состояния данных или результата обработки. То есть система описывается топологией связей и вот этими свойствами, практически через машину состояний. Это интересный подход, сегодня кажется утерянный. Мы моделируем потоки данных, процессы и команды, события, но архитекторы редко говорят про состояния (даже когда упоминают REST, который, по идее, должен как раз вокруг состояний строиться). А сложность архитектуры определяется как раз через сложность нотации, требуемой для описания состояний системы.

Про аналитиков мы уже говорили, а откуда взялись архитекторы ПО?

Термин "архитектура компьютера" вбросил Фред Брукс (руководитель проекта создания OS/360) и Lyle R. Johnson примерно в 1959 году. Определял он её как "то, что нужно знать пользователю". Пользователями тогда называли прикладных программистов.

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

В 1975 вышла книга Брукса "Мифический человеко-месяц", в которой он ввел понятие "программной системы", в отличие от отдельной программы. В том же году Frank DeRemer и Hans Kron опубликовали статьи "Программирование в большом [масштабе] против программирования в малом". В малом — это как раз про написание одиночной программы одним программистом, а "в большом" — как раз проектирование систем, состоящих из многих частей, написанных разными людьми. Но и это не привело к появлению профессии архитектора. Скорее стали разделять кодеров и программистов.

Прошло ещё 15 лет, прежде чем об архитектуре ПО заговорили, как об отдельном предмете. Первая книга про архитектуру появилась в 1990: Laurence J. Best, Application Architecture: Modern Large-Scale Information Processing. Речь тогда в основном шла о переиспользовании компонент, все носились с этой идеей переиспользования и выделения типовых объектов в объектно-ориентированных системах. Была даже целая объектно-ориентированная операционная система — OS/2 от IBM (проигравшая соревнование с Windows, но ставшая культовой в определенных кругах).

В 1992 опубликована статья Dewayne E. Perry и Alexander L. Wolf 'Foundations for the Study of Software Architecture', в которой обсуждается разница между архитектурой и дизайном, а также вводится формула:

Программная архитектура = {Элементы, Формы, Обоснования},

где Элементы делятся на элементы обработки, элементы данных и элементы связи,
а Формы — на взвешенные свойства элементов/системы и отношения между элементами.

В 1993 вышла работа 'An Introduction to Software Architecture' David Garlan и Mary Shaw, а 1996 их же книга 'Software Architecture: Perspectives on an Emerging Discipline' (перспективы зарождающейся дисциплины). Во "Введении в программную архитектуру" уже были перечислены такие архитектурные стили, как "трубы и фильтры", объектно-ориентированный стиль, событийно-ориентированный стиль, слоистые системы и т.д. (так что если вы видите такой список в каком-нибудь курсе или статье — помните, это список из 1993 года!) Основным вопросом было — кто в какой момент кого вызывает.

В 1995 году началась разработка стандарта IEEE 1471 Recommended Practice for Architectural Description for Software-Intensive Systems (будущий ISO 42010). Он вводил идею множества стейкхолдеров, точек зрения и архитектурных представлений. Для каждого архитектура — что-то своё, архитектура в глазах смотрящего.

Параллельно развивались подходы к оценке качества программного продукта: ISO 9126 впервые вышел в 1991 году. К началу 2000-х два направления сошлись: выяснилось, что на качество влияет как раз архитектура. Функции-то система будет выполнять с любой архитектурой, а вот для обеспечения разнообразных -ilities нужно подумать над внутренним устройством. Но это всё было не очень принципиально — пользователей было мало, данных было не очень много, вопросы если и возникали — то только в производительности или в скорости создания/изменения систем.

Звездный час для архитекторов наступил только в конце 2000-х, с расцветом веба — тут мы увидели такие нагрузки и такое количество данных, которых до этого никто никогда не видел. А вместе с ними — распределенные системы и жесткие требования по скорости обновления (TTM). И тогда появились специальные люди, определяющие основные развилки. Впрочем, на самом деле их настолько мало, что US Bureau of Labor Statistics отдельной роли архитектора вообще не выделяет, у них это обобщенные Software Developers, Quality Assurance Analysts and Testers. Так что, возможно, архитектор — это такая же специфическая для РФ роль, как и системный аналитик.

Если вам удобнее использовать Canvas — для микросервисов есть и он, конечно. Точнее, даже не для самих микросервисов, а для ограниченных контекстов (спасибо Денису Мигулину за наводку).

Разделы:

Название
Смысл (Purpose) — бизнес-смысл существования этого контекста. Какую ценность несет этот контекст, кто получит выгоду, и как она обеспечивается? Сюда же можно записать бизнес-драйверы.

Стратегическая классификация, из трех частей:

💎 Уникальность — насколько этот контекст важен для успеха организации?
Он основной (core), то есть обеспечивает ключевое преимущество — или, как на английский манер говорят, является дифференциатором, отличает ваш бизнес от других? Или поддерживающий — обязательный для деятельности, но не уникальный? Или типовой (generic) — такой же, как у других компаний, ничего специфического?

⚙️ Роль в бизнес-модели:
— генерация прибыли,
— повышение вовлеченности/виральности,
— предотвращение рисков (регуляторных, репутационных, ...)
— снижение расходов

📊 Стадия эволюции (по Wardley map):
— Зарождение
— Заказная разработка
— Готовый продукт
— Типовое решение (commodity)

Архетип домена (роль):
— Конструктор (нужен для создания чего-то, возможно — совместными усилиями, возможно — черновика какого-то объекта)
— Исполнитель (выполняет или поддерживает исполнение бизнес-процесса)
— Аудитор (отслеживает выполнение)
— Контролер (принимает решение о возможности выполнения следующего шага, утверждает)
— Блюститель (Enforcer; принуждает другие контексты выполнить определенные операции в соответствии с внешними бизнес-правилами)
— Переводчик (переводит между разными "бизнес-языками")
— Шлюз (контролирует границы и внешние взаимодействия; может совмещаться с ролью переводчика)
— Пузырь (экранирует легаси-систему до её вывода)
— Воронка/трубопровод (перекачивает данные/документы из одного контекста в другой с обработкой)
— Аналитика (собирает и обобщает данные)

Язык домена: какие в этом контексте есть понятия и термины?

Входящие коммуникации: кто в этот контекст посылает сообщения, и какие? Это могут быть другие контексты, пользователи или устройства пользователей, существующие системы. Контексты с точки зрения коммуникаций делятся на восходящие (upstream) и нисходящие (downstream) — восходящие предоставляют информацию/сервисы и публикуют события, а нисходящие используют информацию и потребляют события.

У взаимодействий тоже есть свои типы, или паттерны мэппинга контекста:
— OHS, Open-host Service — контекст предоставляет одинаковые услуги всем, кому они нужны. Он не подстраивается под каждого клиента. Это upstream-контекст.
— CF, Conformist — паттерн для downstream-контекста: он подстраивается под язык upstream.
— ACL, Anticorruption layer — изолирующий слой для downstream-контекста, фильтрующий всю возможную "порчу", поступающую извне.
— SK, Shared Kernel — два контекста разделяют одну (компактную) модель. Создает зацепление, но облегчает понимание.
— PNR, Partnership — это больше про взаимодействие команд, когда они совместно согласуют взаимодействия (каждый может подвинуться)
— Customer / Supplier — отношения upstream/downstream, но, в отличие от OHS, upstream (supplier) зависит от cutomer'а, и учитывает его потребности в своей логике развития.
— PL, Published Language — дополнительный паттерн, определяющий специальный язык/формат для обмена. Типа vCard, или iCalendar, или какой-нибудь FHIR.

По паттерну взаимодействия тоже можно принять решение и зафиксировать на шаблоне.

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

Бизнес-решения: какие приняты решения, политики и бизнес-правила.

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

Метрики верификации: у нас же были драйверы и предположения, а как мы измерим успех?

Открытые вопросы: что ещё нужно выяснить?

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

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

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

Культура чеклистов вообще не очень развита, многие не понимают, что это. Дают просто существительные. [ ] Sync vs. Async/Event-based processing. И что я тут должен поставить?

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

Поэтому пришлось сделать свой чеклист, подходящий для системных аналитиков. Держите:

1. Идентичность и ответственность
1.1. Можем описать ответственность сервиса одной фразой без «и», «а также», «кроме того», «плюс».
1.2. Понятно, какой бизнес-драйвер обосновывает существование сервиса (скорость изменения этого субдомена, масштабирование/нагрузки, сокращение TTM, регуляторные требования/безопасность, снижение/изоляция ошибок и т.п.).
1.3. Можно назвать 1 ключевую бизнес-способность, за которую отвечает сервис

2. Границы и связи с другими сервисами
2.1. Для сервиса понятен список use-case’ов, в которых он:
— ведущий (владеет бизнес-логикой),
— участник (вызывается другим сервисом, реагирует на событие).
2.2. Сервису не нужен прямой доступ в базу других сервисов; только через API/события.
2.3. Есть разумный список зависимостей от других сервисов (входящих и исходящих), нет "всех со всеми".
2.4. Сервис не является "божественным объектом" — не пытается делать всё для всех.

3. Данные и инварианты
3.1. Определены основные агрегаты/сущности, которыми владеет сервис (список 3–7 штук).
3.2. Для ключевых данных описаны инварианты: что "никогда не должно нарушаться"
3.3. Для каждого инварианта определен механизм, за счет которого он соблюдается (бизнес-логика, ограничения БД, контракты взаимодействия)
3.4. Для сервиса определены объемы и профили хранения данных (типичный объем хранения; прирост; вывод устаревших данных/архивация; доля "горячих" и "холодных" данных)
3.5. Для 1–2 основных сущностей сервиса описаны: этапы жизненного цикла (статусы), допустимые переходы между ними, кто инициирует какой переход (use-case / входящее событие).
3.6. Для ключевых сущностей предусмотрены все операции CRUD (понятно, кто их делает, есть API) + архивирование/хранение истории
3.7. Приняты решения по модели чтения (CQRS, Event Sourcing)

4. Контракты, схемы и API
4.1. Составлен список внешних операций:
— команды (изменяют состояние),
— запросы (чтение),
— доменные события (что сервис публикует).
4.2. Методы разумно гранулированы: нет «мега-методов», которые делают всё сразу, и нет чрезмерно мелких операций, создающих "болтливые" (chatty) API.
4.3. Для ключевых операций определена модель ошибок и контракты ответов/обработки:
— ошибки бизнес-уровня (валидация полей, попытки нарушения инвариантов, недостаток данных из-за Eventual Consistency),
— какие — технические,
— как клиент понимает, что делать (повторять/не повторять/обращаться в поддержку).
4.4. Определена стратегия эволюции структуры API и схем данных: принудительное обновление клиентов / поддержка нескольких версий API / схем
4.5. Все события описаны как контракт: есть описание схемы; определены гарантии доставки / сохранения порядка
4.6. Определены идемпотентные операции и механизмы обеспечения идемпотентности

5. Надёжность, производительность, наблюдаемость
5.1. Для ключевых операций определены SLO:
— латентность
— доступность
— процент ошибок
5.2. Поведение при отказах: понятно, что делает сервис:
— при падении зависимого сервиса,
— при перегрузке (ограничение, деградация, очереди),
— есть ли таймауты, ретраи, circuit breaker, алгоритм перепосылок
5.3. Определена тактика горизонтального масштабирования и распределения нагрузки: round robin, деление по данным, по клиентам
5.4. Выявлены потенциальные узкие места (БД, внешняя интеграция, блокирующие операции, большие файлы, состояния гонки), приняты решения по их расшивке
5.5. Определены отслеживаемые бизнес-метрики, технические метрики и ключевые события для логирования

Обсуждение FizzBuzz напомнило про старую задачку на моделирование классов и взаимодействия: как замоделировать ситуацию "человек пьет кофе из кружки".

Очевидно, у нас будут классы "человек" и "кружка", и, например, уровень кофе в кружке. А вот про взаимодействие вопрос: где живет метод "пить"? Класс "человек" отправляет сообщение "пить(объем кофе)" классу "кружка" ( person->cup.drink(30) )? Или человек пьет, а кружка тогда что делает? ( person.drinkFrom(cup,30) )

Я не помню, у кого я видел обсуждение этой задачи. Но пока искал, нашел прекрасную статью Грегора Хопа (соавтора "Паттернов интеграции корпоративных приложений") с иллюстрацией синхронной и асинхронной интеграции на примере Starbucks.

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

А вот приготовление выполняется асинхронно:
— разные напитки требуют разного времени приготовления
— разное оборудование может быть использовано параллельно
— приготовление может вставать в очередь, когда оборудование занято
— заказы могут быть готовы не в той последовательности, в которой были сделаны

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

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

— Идентификатор корреляции (Correlation ID), чтобы сопоставить приготовленный напиток и заказ. В Starbucks в качестве этого идентификатора используют имя клиента.
— Обработка исключений. Когда описывают "саги", всегда пишут про компенсирующие действия. Но Хоп пишет, что есть три варианта:

1. Списание. Если транзакция завершилась неудачей, мы просто ничего не делаем. А что уже сделали — выбрасываем (списываем). Возможно, механизм исправления ошибки будет стоить дороже. Иногда у нас просто нет другой возможности, а иногда это бизнес-решение: если клиент не забрал напиток, его через какое-то время нужно вылить.

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

3. Компенсирующие действия — выполнение обратных операций. Если мы совсем не смогли приготовить кофе, придется вернуть деньги.

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

Что ещё можно вспомнить? Если рассмотреть другие закусочные, то можно увидеть паттерн Claim Check — когда клиент получает не финальный (тяжелый) результат, а чек, с которым он приходит за заказом. Тогда идентификатор корреляции — номер заказа, который есть на чеке.

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

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

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

У программистов есть классическая, даже легендарная задача на собеседовании: FizzBuzz.

Нужно написать программу, которая для каждого числа от 1 до 100 выдает либо Fizz (если число делится без остатка на 3), либо Buzz (если число делится без остатка на 5), либо FizzBuzz, если число делится без остатка и на 3, и на 5. Если число не делится ни на 3, ни на 5 — нужно выдать само это число.

Задачу так часто давали разработчикам на интервью, что это стало уже анекдотом.

А решается она настолько просто, что появились разновидности с усложнением: FizzBuzz только с двумя if; FizzBuzz с двумя if без использования переменных; вообще без if и без переменных; без использования операции взятия остатка и т.д.

Есть решения невероятной сложности — например,
FizzBuzz на косинусах и дискретных преобразованиях Фурье: https://habr.com/ru/articles/969856/ (осторожно, в посте для вывода используется формула Эйлера комплексными числами, я вас предупредил), или
FizzBuzz на TensorFlow, на основе многослойного перцептрона со скрытым слоем: https://habr.com/ru/articles/301536/.

Впрочем, ближе к нам корпоративная реализация FizzBuzz: https://habr.com/ru/companies/contentai/articles/173885/ (язык — Java; 102 файла, разложенных по 44 папкам; используются такие ООП-паттерны, как Стратегия, Абстрактная фабрика, Декоратор, Адаптер; есть тесты). Впрочем, как пишут многие критики, до настоящего ПО корпоративного уровня этому решению далеко.

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

Чем занимались системные аналитики 50 лет назад? Да тем же самым.

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

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

Зато я исследовал историю профессии "системный аналитик", и даже писал про неё тут: https://t.me/systemswing/284

Но архитекторы, конечно, говорят, что это не те аналитики, и занимались они совсем другим. Что ж, пришлось найти статью 1973 года JD Couger, 'Evolution of business system analysis techniques'. Эволюция техник анализа бизнес-систем! Эволюция, понимаете? 1973 год, это ещё методы структурного анализа только-только разрабатываются. Внутри там вообще сказка: он прослеживает истоки системного анализа до 1920-х, к Тейлору. Использование электронных машин — с 40-х. А 70-е — это уже третье поколение техник!

А вот чем занимались аналитики в 1970 годы:

Системный анализ заключается в сборе, организации и оценке информации о системе и среде, в которой она функционирует.

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

Понимание роли системного аналитика облегчается обращением к этапам цикла разработки системы. В данной статье выделяются семь этапов разработки системы:
Этап I — Документирование существующей системы
Этап II — Анализ системы для установления требований к улучшенной системе (логическое проектирование)
Этап III — Проектирование компьютеризированной системы (физическое проектирование)
Этап IV — Программирование и разработка процедур
Этап V — Реализация
Этап VI — Эксплуатация
Этап VII — Техническое обслуживание и модификация

Таким образом, системный анализ касается этапов I и II цикла разработки системы. Результатом системного анализа является логическая структура новой системы: спецификации входных и выходных данных системы, критерии принятия решений и правила обработки.

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

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

Расширение области применения и усложнение систем повышает сложность системного анализа и проектирования. Проектирование интеграций влечет за собой увеличение «начальных» затрат.

Ну всё то же, чем мы занимаемся прямо сейчас, вплоть до проектирования интеграций! Ничего принципиально не поменялось за 55 лет (вот только архитекторы ещё появились).

Отдельно интересно, что там уже есть нечто вроде диаграмм BPMN (из 50-х годов!), смотрите какие они милые.

Я тут вместе с ChatGPT немного подумал про разделение ролей и протечку абстракций, и вот что у нас получилось, полюбопытствуйте:

Абстракции есть не только в архитектуре. Роли на уровне организации распределены тоже по слоям абстракций, с обещанием "вам на этом уровне не нужно об этом думать". Это [само]обман — абстракции всегда дырявы. С этим не нужно бороться, это нужно учитывать.

Частая ошибка — проводить границы ролей по артефактам ("кто описывает процессы, кто требования, а кто API"). Артефакт — след деятельности, а не её смысл. А граница проходит по языку, точнее — по модальностям. Сергей Нужненко любит упоминать логику, ну вот всё проектирование — это набор модальных логик, своих для каждой роли. По сути, описание разных миров с операторами достижимости: □ "во всех достижимых мирах" / ◊ "в некотором достижимом мире".

По ролям эти логики раскладываются так:

Продакт (владелец ценности). Модальность пользы: "желательно/целесообразно/вероятно окупится | во всех мирах/в отдельном мире". Это логика предпочтений и неопределённости. "В большинстве релевантных сценариев это даёт пользу [и это лучше, чем другой вариант], мы твердо уверены в этом".

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

SA (владелец модели). Динамическая и темпоральная модальность: "после события X", "всегда", "в состоянии системы S1 | допустимо/обязательно". Сюда же модальность последовательности ("после выполнения действия A допустимо/обязательно B"). В общем, это про целостность, "во всех достижимых состояниях модели инварианты сохраняются".

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

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

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

ИИ предлагает регулярные ритуалы для выявления взаимовлияний — по-моему, он их просто на ходу придумал, цитирую без правки:
Feature framing (PM ведёт): гипотеза ценности + ограничения + метрика + допустимые компромиссы по качеству.
Policy workshop (BA ведёт): правила + исключения + спорные кейсы + "кто имеет право решать исключения в рантайме".
Model review (SA ведёт): сущности/состояния/события + инварианты + контракты интеграций + миграции.
Quality attribute workshop (архитектор ведёт): сценарии качества (нагрузка, отказ, атака) + бюджеты (latency/cost) + деградации.
Design/operability review (dev ведёт): стратегия тестирования + наблюдаемость + откаты + SLO-реальность.

А роли, в конечном итоге — это предохранители необратимых потерь. Вот смотрите, что можно необратимо потерять:
— данные, если не собирали, то уже и не соберем; если необратимо испортили — обратно не восстановим (SA)
— деньги — из-за атак или сбоев (архитектор, ИБ) или неверного расчета экономики (продакт)
— доверие рынка / право на деятельность (продакт, BA)
— возможности развития (архитектор, разработчик)

Вот такая раскладка, что думаете?

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

— У нас протечка.
— Протечка чего?
— У меня всё сиденье мокрое.
— Должно быть, это абстракции протекли.

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

В институте нас очень аккуратно провели по всем уровням абстракций при создании электронной аппаратуры:

Сначала ты анализируешь задачу — твоё устройство вообще зачем? Какие функции оно будет выполнять?

Потом строишь алгоритм, или, например, карту Карно. Или целую функциональную схему (для цифровых схем — логическую), где только нолики и единички бегают.

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

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

Кое-что из этого можно и нужно решать программно — например, нагрев. Опять протечка!

И эти протечки нам могут подсказать границы ролей. Если в бизнес-процессе участвует смежная система — какое у аналитика предположение о её ответе? Она всегда доступна и отвечает мгновенно? Это бизнес-анализ. Ответ занимает столько-то миллисекунд в 95% случаев? При получении ответа 500 мы ждем 3 секунды и пытаемся выполнить запрос повторно? Это системный анализ/проектирование. Что мы показываем пользователю во время этого ожидания, чтобы он не нажал ещё несколько раз, не видя отклика? Это протечка абстракции: мы должны учесть детали реализации. В устранении протечки должны участвовать две роли. Перекладывать на бизнес-аналитика задачу "представить себе, как это будет реализовано" — это с больной головы на здоровую, не его зона ответственности, не его уровень абстракции. Мы же стараемся, чтобы более верхний уровень не знал о деталях реализации нижележащего.

Можно попробовать ещё накидать типовых точек протечек:
— Поиск/фильтрация по большому объему данных. А вы об индексах подумали? А может, запретим выдачу без фильтров, а то слишком много результатов, это full scan — протечка! Мы не должны думать об устройстве базы. Нужна совместная работа двух ролей. Сюда же — пагинация, поэтому её так часто БА забывают.
— Форматы данных при передаче. JSON? XML? Avro?
— Парадигма хранилища (реляционное, колоночное, документарное)
— Домены данных в хранилище (типы + ограничения на формат/диапазон, а вот бизнес-правила — это уже уровень выше)
— Кэширование, управление кэшированием (это и для системного аналитика часто вне рассмотрения)
— Распределение обращений по однотипным узлам, балансировка нагрузки
— Стратегии обеспечения согласованности, CAP/PACELC, уровни согласованности данных
— Развертывание, обновление
— Поддержка разных окружений (браузеры, ОС, оборудование, подключение к сети)

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

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

В конечном итоге, кажется, всё это укладывается в проверочный вопрос "если системы нет, то как это будет исполняться?" Пока нет конкретной реализации системы — это бизнес-анализ, нужно учитывать особенности реализации — системный.

"Назови три"

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

Но у всех них, однако, можно чему-то научиться. Вот, например, попалась мне статья с LessWrong, а потом и вторая. LessWrong — это главный ресурс движения рационалистов. Ну, теорема Байеса, борьба с когнитивными искажениями, "Гарри Поттер и методы рационального мышления", вот это всё.

Статья про конкретику (в английском, как обычно, есть два отдельных слова: specific и concreteness). Я думаю, мы все с этим сталкиваемся, когда говорим с заказчиками. Да и когда между собой спорим, что уж тут.

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

В статье приводят в пример разбор дейтинг-стартапа на школе YCombinator: на вопрос, а что конкретно лучше он делает по сравнению с обычными способами общения, автор отвечает нечто вроде "конкретно наш продукт предоставляет более лучший способ коммуникации для людей, они много что делают в реальной жизни, и пытаются это делать онлайн, и мы даем им онлайн-инструмент, чтобы делать это". Понятно, в чем фишка стартапа?

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

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

В изучении иностранных языков есть такая игра: "назови три". Тебе дают общее понятие, и нужно назвать три конкретных. Три предмета одежды, три кухонных прибора, три водоплавающих птицы и т.д. Очень полезное упражнение, им можно и собеседников на интервью возвращать к конкретике. Приведите пример, пожалуйста. Ладно, не три, хотя бы один. Хотя лучше несколько — для разных ситуаций.

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

Я раньше не мог понять, что заставляет людей возноситься к абстрактным понятиям. LessWrong утверждает, что это когнитивное искажение, связанное с экономией мыслетоплива и подстановкой атрибута — назвать абстрактное (всё объясняющее) понятие проще, чем подумать над конкретным примером. LW предлагают ловить это у себя: как только заметили слишком абстрактные слова или мысли — остановитесь и придумайте конкретный пример. Но для нас, как аналитиков, очень важно вытаскивать конкретику из других людей, поэтому и на собеседниках нужно использовать этот прием, просить привести примеры — типичные и исключительные.

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

Ну и завершая тему DDD (готов уворачиваться от помидоров) — ни в одной рекламной статье вам не расскажут про "DDD трилемму" — аналог CAP-теоремы для моделирования доменов.

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

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

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

Вот ключевая статья на эту тему от Владимира Хорикова https://enterprisecraftsmanship.com/posts/domain-model-purity-completeness/ + преза на русском.

Там простой пример: проверка уникальности email'а при регистрации пользователя. Как его делать? То ли передать с уровня домена в контроллер (и там сначала проверить существование пользователя с таким email), то ли прямо из модели пользователя сходить в хранилище поискать email'ы, то ли поднимать всех пользователей из хранилища на уровень домена, и отдавать модели пользователя (сожрет всю память).

Ну и вот, выбирайте, как хотите. И так, и так, и так будет криво, вопрос — с какой кривизной вы готовы столкнуться?

Это, в общем, следствие старого Закона дырявых абстракций Джоела Спольски: все нетривиальные абстракции дырявы.

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

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

И вот эти красивые картинки — из метода QFD, Quality Function Deployment. А сама картинка называется "Дом качества". Придуман он, конечно, японцем — Йодзи Акао (Yoji Akao) и, конечно, в 60-е годы. И, разумеется, среди ит-шников мало известен, хотя этот метод — часть движения бережливого производства.

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

QFD учитывает приоритет свойств, силу связей между однотипными свойствами продукта и её знак — усиление или снижение (те самые tradeoffs, или противоречия): ++, +, [](нет связи), -, —. Заодно он расставляет веса свойств. Причем, чтобы не спорить — в чем тонкая разница между 0.2 и 0.3, предлагается всего три значения: 1,3,9 (ещё 0 - свойство не важно, но такие свойства и не появляются в оценке).

Дальше на пересечении строится матрица зависимостей: какое "как?" как влияет на какое "что?". В результате получаются взвешенные оценки каждого свойства, по сути — профиль решения. Его можно сравнить с конкурентами. А снизу приписать техническую возможность и сложность (стоимость) реализации.

Вот так можно всю систему на одной картинке визуализировать с приоритетами, профилями и направлениями улучшений.

Делали когда-нибудь такой анализ для своих продуктов?