>> Какие ограничения имеет подход 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) Альберто Брандолини
Как только оно появляется – архитектура начинает работать на бизнес, а не наоборот.

О декомпозиции через Ограниченные Контексты

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

Туда же и декомпозицию монолита на микросервисы (что тоже некорректная формулировка и подход).

Давайте разбираться.

Традиционная «декомпозиция системы» в инженерном понимании почти всегда подразумевает:
1. есть единая целостная модель системы
2. мы делим ее на части
3. части в совокупности «покрывают» целое (часто еще и без пересечений или с минимальными пересечениями)

В таком понимании:
- есть единое целое,
- есть разбиение этого целого

Внезапно, Bounded Context так не работает. И переход от монолита к микросервисам так не работает :)

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

То есть мы не делим модель на куски, мы конструируем несколько моделей, которые опираются на:
- свой лексикон (Ubiq. Language)
- свои инварианты
- свой контекст применения

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

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

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

Мысли вслух про разработку с помощью AI

Я вот пользуюсь перплексити, чатгпт, курсором и другими инструментами. Разработчики инструментов в том числе продвигают разработку через эти инструменты.

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

Ведь они стоят буквально в авангарде этих заявлений.

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

PS: вот взять перплексити, там же в интерфейсе баг на баге и багом погоняет, если активно использовать… а кому вообще удобно использовать gemini?

Из обсуждения и наблюдений получается парадокс :)

Назову его парадоксом потребности в ИИ Баранова))) Хотя уверен, я не первый, но вдруг:

Чтобы эффективно использовать AI, нужна квалификация, при которой AI уже не нужен.

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

Почему падает биткоин?

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

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

Выглядит как отличная схема - и заработать на крипте и разогнать акции.

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

В чем проблема?

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

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

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

Началась распродажа, что оказало давление на рынок.

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

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

Но юридически все официально - через биржу и корп финансы.

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

Потребность в [глубоком] анализе IT-системы которую вы сами проектировали и разрабатывали говорит о том что у вас проблемы… с чем?

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

Потребность в [глубоком] анализе IT-системы которую вы сами проектировали и разрабатывали говорит о том что у вас проблемы… с чем?

Глобально проблема в преобразовании организационного знания.
Согласно теории Такучи и Нонака (а на кого нам еще опираться), их спиральной модели, явно присутствуют витки преобразования неявного знания в явное.

На изображении показано, что происходит.

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

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

Но тут все не так просто, в этом процессе есть минимум три функции:
- Функция сохранения знания
- Функция передачи знания
- Функция использования знания

Теперь ближе к конкретике.

Три ключевые причины, которые проецируются на эту модель:

1. Архитектурный долг
Когда вы писали систему, вы «сэкономили» время на документации. Вы взяли кредит. Сейчас вы не просто работаете, вы платите проценты по этому кредиту. То время, которое вы тратите на анализ – это штраф за то, что решения не были зафиксированы тогда и чем дольше система живет без описания, тем дороже стоит каждое следующее изменение. Это называется «эрозия архитектуры» — реальность уплыла от задумки, и никто не знает, где правда.

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

3. Героизм
Я этот пример приводил на курсах по DevOps как один из видов потерь в бережливом производстве.
Если для понимания системы нужен конкретный человек, значит, система неустойчива. Это монополизация знаний, иными словами Bus Factor = 1
4. Бизнес находится в заложниках у памяти сотрудника :) И это, внезапно, не признак незаменимости сотрудника, а признак хрупкости бизнеса. Но героем быть выгодно и приятно :)

В качестве конкретных шагов, что можно сделать прямо сразу:
1. Установить налог на знания. Ни одно решение не считается завершенным, пока оно не задокументировано - буквально, например, pull request уходит в реджект.
2. Снизить bus factor - минимум три человека хорошо знают какую-то одну область. Сессии по передачи знаний здесь хорошо работают. Кстати, Event Storming с дальнейшим погружением в архитектуру достаточно не плох в этом.
3. Выделить время на возврат долга и добавить задачи в бэклог. Вычистить устаревшее, обновить схемы, артефакты, документы. Самый простой и сложный пункт одновременно, тут и время надо выделить и дисциплина нужна.

Разумеется и причин и средств на порядки больше, и в каждой компании/команде они могут быть «немного» своими, тут книгу написать можно, но в общех чертах постарался сформулировать, чтобы отразить основную мысль.

Отличное наблюдение!

Если проследить хронологию, то сюда прекрасно подходят слова Шейха Рашида ибн Саида Аль Мактума: «Мой дед ездил на верблюде, мой отец ездил на верблюде, я езжу на «Мерседесе», мой сын - на «Ленд Ровер», но его сын будет ездить на верблюде».

Изобилие ослабляет, а трудности закаляют.

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

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

Что происходит в кризис?
- оптимизация
- сокращение

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

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

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

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

Простые расчеты для одной и той же системы:

- Монолит - 1 ставка админа, 1 senior, 1 middle, 3 junior

- Распределенная система - 3 ставки админа, 3 senior, 2 middle, 1 junior

И в зависимости от размеров компании, можно помножить на 10 или 100.

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

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

Новый кейс в Архитектурных Этюдах и… это случилось!

Тема «Архитектура управления проектированием в гражданском строительстве»

Буквально, alma mater архитектуры 🙂

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

https://t.me/archicases/1/8326

Запрос автора:
— какие сложности в реализации видит сообщество;
— что бы поменяли в предложенной архитектуре.

Катастрофа была неизбежна | GEO
https://www.youtube.com/watch?v=l_QcNZqUyN4

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

Здесь и:
- Тема урезания скоупа для mission critical
- Придуманные цифры для оценки вероятности отказа
- Бюджетные войны
- Политика
- Пренебрежение безопасностью

В общем, я гарантирую, что будет интересно.

Про полноту моделей.

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

Эта мысль должна какое-то время настояться. Особенно сложно, как мне кажется, она проходит барьер у тех, кто всю жизнь строил полные модели, - MDM, золотые записи, ….

В Model Driven есть эффект - каждые новые 5-10% охвата кейсов стоят в разы дороже по сложности, но дают все меньше практической пользы.

Немного практики.

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

На золотую запись и MDM можно смотреть как на каркас онтологии и «каталог» ссылок, а не как на исчерпывающую модель: они дают устойчивые идентификаторы, базовые атрибуты и трассируемость к источникам и тогда это не конкурирующая «полная модель мира», а слой согласования между доменными моделями: каждое приложение держит свою контекстную правду, опираясь на общий идентификатор и базовые атрибуты.