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

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

Выложил на хабр статью по оценке типовых и R&D задач.

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

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

https://habr.com/ru/articles/965462/

А еще в субботу выступаю на Analyst Days со схожей с ArchDays темой, но уже для аналитиков, и здесь будет про то, на какие red flags обратить внимание аналитику.

Если кто будет на конференции, можем встретиться, пообщаться на злободневные темы после выступления, оно будет в субботу в 12:00 в Секции А.

https://analystdays.ru/ru/talk/141496

#ArchDays продолжило тему встройки приложений с ИИ в ИТ-ландшафт. Александр Войновский и Олег Зоткин из Газпром Нефть показали свои архитектурные схемы для такого ландшафта, Руслана Серкина рассказывал о том, какие технические долги ИИ помогает разгребать, а какие -- приносит, а Павел Кан рассказывал про построение систем на основе маленьких специализированных моделей. Но были и чисто архитектурные доклады, среди которых надо отметить рассказ Сергея Баранова про экономические аспекты архитектурных решений со вполне годными моделями и, главное, кейсами оценки конкретных решений. Читайте отчет https://mtsepkov.org/ArchDays-2025

Смотрите, какая интересная новость:

Reading a quantum clock costs more energy than running it
https://phys.org/news/2025-11-quantum-clock-energy.html

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

Глазами архитектора это означает концентрацию усилий не на бизнес-логике (квантовые алгоритмы), а на алгоритмах считывания и преобразования данных - протоколах и API в привычной нам терминологии.

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

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

Я упомянул единую платформу, есть некоторые заблуждения на этот счет, что единая платформа - это, условно, монолитное решение. Это не так.

Платформа и ее границы определяются границами стандартов, принципов и согласованных интерфейсов взаимодействия.

Современная платформенная архитектура базируется на принципе decoupling & integration - это деление на модули при одновременном обеспечении их бесшовного взаимодействия через стандартизированные API и интерфейсы.

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

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

А я сейчас много занимаюсь скрещиванием :) Скрещиванием DDD и LLM. И пока DDD здесь стыкуется даже органичнее, чем с поиском границ микросервисов.

Ubiq. Language (в своем строгом определении), например, повышает качество промтов и снижает уровень галлюцинаций за счет того, что промты пишутся на языке ограниченной контекстом модели, которая использует тот же язык, - не происходит смешения моделей.

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

Публичный кейс по Event Storming ✅

https://scrumtrek.ru/cases/eventstorming-v-ecom-tech/

А если так подумать, то здесь раскрыт интересный конфликт, где-то между вот этими всеми ЭйАй еще архитектор сидит 👀 и потирает руки 🙂
https://www.youtube.com/watch?v=oPr4jk6XMJY

Закончился очередной корп курс по стратегическим паттернам Domain Driven Design. И я хочу публично написать ответы на вопросы, которые участники сформулировали в качестве ожиданий до начала курса. Будет серия простых постов вида Q&A, чтобы можно было пересылать =)

>> Какие существуют паттерны в DDD? 🧐

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

В DDD все паттерны делятся на стратегические и тактические.

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

▪️Ubiquitous Language – общая терминология для разработчиков и бизнес-экспертов
▪️Core Domain, Supporting Domain, Generic Domain – классификация поддоменов по важности для бизнеса
▪️Bounded Context – четко определенные границы, в которых применяется конкретная модель домена
▪️Context Map – визуализация отношений между ограниченными контекстами

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

Тактические шаблоны применяются внутри одного ограниченного контекста для реализации бизнес-логики:

▪️Entity (сущность) – объект с уникальной идентификатором, сохраняющейся во времени
▪️Value Object – неизменяемый объект без идентификатора
▪️Aggregate – кластер связанных объектов (value objects + entities), обрабатываемых как единое целое, с корневой сущностью (Aggregate Root)
▪️Domain Service – операции, не принадлежащие конкретной сущности (а не «микросервис», как некоторые думают =) )
▪️Repository – абстракция для доступа к данным
▪️Domain Event – значимое изменение состояния в домене
▪️Factory – создание сложных объектов

Архитектурные паттерны, часто используемые с DDD:

▪️Layered Architecture – разделение на слои: presentation, application, domain, infrastructure
▪️Hexagonal Architecture – изоляция бизнес-логики от технических деталей
▪️CQRS – разделение операций чтения и записи
▪️Event Sourcing – сохранение изменений состояния как последовательности событий

То есть DDD достаточно богат на паттерны. И они связаны друг с другом. Например, без исследования предметной области как таковой не определить границы применимости модели (Bounded Context) ну просто потому, что – а в чем вы будете границы проводить? Микросервисы сделали очень популярным паттерн Bounded Context, сотни тысяч статей, жаль, что в большинстве из них не указывается, что вообще-то сначала нужно построить модель домена, провести классификацию (найти Core Domains), а потом уже в них под конкретное решение проблем провоить границы.

#dddbasics ✅

>> Какие ограничения имеет подход DDD? 🧐

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

Из основных.

Высокая стоимость внедрения
Речь о полном внедрении, что не всегда требуется. Например, стратегическую часть можно использовать отдельно и даже вне ИТ. Модели есть везде.
▪️Значительные начальные инвестиции времени, так как требуется глубокое понимание бизнес-домена
▪️Достаточно крутая кривая обучения, и здесь мозги Эрика Эванса сыграли злую шутку, – на мой взгляд он изначально достаточно сильно усложнил подход. Рекомендую сначала прочитать книгу Влада Хононова по DDD, это сделает вход намного более простым и органичным, более сложные концепции будут нанизываться на общее понимание.

Требования к команде и организации
▪️Требуется достаточно высокая квалификация команды как в ООП, так и в DDD
▪️Необходимо активное вовлечение доменных экспертов, что возможно не в каждой культуре

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

Ну и, конечно, DDD нужен не везде. Даже Эрик Эванс говорил – мы не можем сделать все максимально хорошо и нам нужно понять, где это «максимально хорошо» необходимо в первую очередь (спойлер – в Core Domain).

DDD не даст существенных преимуществ, когда:
▪️Это простенькие CRUD-приложения; сел и сделал, исследовать там часто нечего
▪️Низкая бизнес-сложность, но высокая техническая (мало бизнес-логики, но серьезные сложности с обеспечением высокой нагрузки, – здесь другие подходы)
▪️Краткосрочные проекты, вроде временный систем, прототипов, – затраты просто не окупятся

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

Однако применение стратегических паттернов куда более широкое, оно вышло за пределы канонического DDD и развивается в том числе самостоятельно, чего только стоят работы Nick Tune и DDD-crew (https://github.com/ddd-crew) в этом направлении. Поэтому не унываем, DDD только набирает обороты, а органичная интеграция с LLM в ближайшее время даст еще один виток развития практик под зонтиком DDD

#dddbasics ✅

Сегодня хочу поделиться своими размышлениями по итогам онлайн-просмотра конференции ArchDays 2025. Я уже успел посмотреть все доклады и хочу поразмышлять над ними и над ситуацией в отрасли в целом.

https://telegra.ph/Razmyshleniya-po-itogam-ArchDays-2025-11-24

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

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

Но есть и, что называется, вторая сторона медали, второй вход - человек (или агент). Молчат об этом. И, внезапно, модель данных, от пользователя/агента должна быть такой же. Кто бы мог подумать :)

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

В общем, у меня этот квартал выдался каким-то аномальным на консалтинг в области стратегических паттернов DDD и Event Storming и похоже пора расширять старенькое выступление «что можно получить из Event Storming» еще одним пунктом - нормально работающие LLMки :)

Публикую отчет https://mtsepkov.org/AnalystDays-2025b с конференции AnalystDays для меня оказалась очень содержательным завершением темы ИИ на осенних конференциях: SQAdays, Highload, ArchDays и Teamlead. Основных векторов развития два: (1) приложения с ИИ научились технологично встраивать в ИТ-ландшафт наряду с обычными приложениями, переходя от DevOps к ML-ops и (2) LLM успешно работает как индивидуальный помощник или специализированный функциональный агент, и теперь пора переходить к проектированию команд и компаний в целом с участием ИИ-агентов. На Teamlead я смог сформулировать: широко вещаемая цель замены людей или команд разработки на ИИ-агентов -- ложная, ведь никто не ставит целью собрать мощную команду из джунов, а ИИ по многим характеристикам пока именно джун. А вот задача эффективного включения в команды и компании ИИ-джунов с уникальной компетенцией быстрого доступа к любым знаниям мира, которая присуща LLM, в отличие обычного джуна -- вполне разумная и содержательная. И именно этот вектор получил развитие на AnalystDays в визионерском выступлении Димы Безуглого, который рассказывал о таком направлении развитии и о возможном месте аналитика в новом мире. А еще у Димы было гротескное представление мира ИТ, где менеджеры, не видевшие клиента и не знающие как работает система, ставят задачи разработчикам, не знающим ничего о компании.

Помимо выступления Димы, про ИИ я слушал Reydan Yasar, Анну Гурову, Дарью Рассказову и Елизавету Французяк. Кроме того, я хочу обратить внимание на выступления Анны Обуховой, которая впервые показала схему дофаминового пути мозга с уровнями энергии, Сергея Баранова, продолжавшее тему стоимости архитектурных решений, начатую на ArchDays, Светланы Дорониной с интересными кейсами для аналитика. А вообще все выступления, которые я слушал, были интересными, ПК конференции собрали хорошую программу. И мастер-классов тоже было много.

Как же мало уникальной бизнес-логики в компаниях, вы бы только знали :)

После сотен сессий Event Storming это становится настолько очевидным!

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

Все внутренние системы проведения платежей через внешних провайдеров с точки зрения предметной области - одинаковые на процентов 80.

Все складские системы с точки зрения предметной области одинаковые процентов на 90.

Магазины похожи процентов на 80 друг на друга..

Что не возьми - все почти одно и то же :)

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

Продолжение про «похожие процессы» и про важность DDD.

(кажется, получился очень глубокий и важный пост про важность DDD)

Конкретным профессиям и их внутренней кухне (туризму, логистике, финансам, медицине) в профильных вузах учат годами. Для тех, кто прошел такой путь, типовые процессы внутри их отрасли выглядят очень похожими: одни и те же шаги, одни и те же риски, одни и те же точки принятия решений. Но есть один нюанс…

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

И вот спец по туризму открывает турфирму. Нанимает сотрудников, поднимает продажи, строит партнерства – бизнес как‑то работает.

В какой‑то момент становится тесно в Excel и мессенджерах и он нанимает разработчиков: «пора автоматизировать».
Что разработчик, который 5 лет учился на разработчика, знает о туризме? Ну… есть Турция, Египет, самолетом можно долететь, отели бывают с завтраком и без….

У него нет такого же целостного и глубокого представления о процессе, как у эксперта в туризме. Прилетает задача: «сделай бронь места в гостинице, вот тут предоплата, вот тут подтверждение». Он честно реализует эту отдельную фичу.

Потом еще одну.
Потом «быструю доработку к сезону».
Потом срочный костыль «потому что партнер меняет правила».

Со временем разработчик, конечно, начинает лучше понимать процесс, картинка становится целостнее…. но к этому моменту система уже обросла заплатками так, что ее страшно трогать. «Сначала требования определяют архитектуру, а затем живут в ней» (c) мой

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

С должным усилием, упорством и желанием этот разработчик вырастает до архитектора.
Он наконец смотрит на весь процесс целиком и понимает, что 90% кода можно выбросить и заменить несколькими коробочными продуктами, одним внешним сервисом и небольшим слоем кастома. Потому что реально уникальное – вот эти самые 5%, где и прячется конкурентное преимущество бизнеса, а все остальное – типовой, стандартный Generic.

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

Пока этого понимания нет, «в прод идут лишь предположения разработчиков о предметной области» (c) Альберто Брандолини
Как только оно появляется – архитектура начинает работать на бизнес, а не наоборот.