Забытое искусство конструирования URL. Нашел классную статью про URL'ы: https://alfy.blog/2025/10/31/your-url-is-your-state.html

Главная идея: URL'ы — это состояния. Похоже на REST, да? Всё крутится вокруг состояний приложения, и каждый URL представляет некоторое состояние. Это относится и к API, а к web-приложениям — в особенности.

При этом URL — это такая пограничная тема между бэкендом и фронтендом. Кто за них отвечает? Кто их проектирует? Или как они вообще появляются? Иногда — аналитик (для API). Для приложения — непонятно, кто.

Современные фронтендеры часто вообще не понимают, о чем речь. Типичное проявление: вы устанавливаете фильтр на таблицу или список, потом переходите к конкретному экземпляру, потом возвращаетесь обратно — и все фильтры сброшены. Ну конечно, а где их сохранить? В cookie? В localStorage/sessionStorage? В внутрибраузерной indexedDB? Так много вариантов и очень сложно в реализации. Вот бы был простой способ сохранить это состояние без всяких баз.

И этот способ есть — это URL. Хорошо спроектированные ссылки бесплатно дают сразу несколько возможностей:
— шеринг: я отправляю ссылку, и получатель видит ровно то же, что я вижу;
— закладки: я сохраняю закладку = сохраняю конкретный момент времени;
— история: кнопка "назад" в браузере/смартфоне просто работает;
— глубокие ссылки и вложенные состояния: можно попасть напрямую в какое-то специальное состояние приложения.

Основной элемент URL для этого — query parameters, параметры запроса(строка после ?). И такой недооцененный элемент URL, как фрагмент (строка после #).

Эти части URL можно использовать очень творчески, например, в GitHub добавление фрагмента #L108-L136 будет означать "показать исходник, выделив в нем строки 108-136".

А вот как записываются в URL координаты в Google Maps: @22.443842,-74.220744,19z

Состояние чего мы можем хранить в URL? Какие данные о состоянии приложения?
— Поисковый запрос
— Фильтры
— Пагинация
— Сортировка
— Модель просмотра (таблица / список / карточки)
— Период дат/времени
— Диапазон строк или ещё чего-то счетного (в отличие от пагинации, здесь имеется в виду подсвечивание на странице)
— Координаты или область просмотра для больших графических представлений (карты, доски)
— Выбранные опции, выделенные элементы, активные вкладки, раскрытые/закрытые элементы в древовидных структурах
— Параметры конфигурации интерфейса, например — язык или тема (темная/светлая)
— Фича-флаги, варианты A/B-тестов

Какие типовые подходы есть к кодированию информации в query:
Значения параметров через & : ?debug=true&analytics=false или даже без значения: ?mobile (самого наличия флага уже достаточно)
Множественные значения:
?languages=javascript+typescript+python или
?languages=javascript,typescript,python
Массивы: ?ids[0]=42&ids[1]=73 (php поддерживает парсинг такого автоматически)
Структурированные данные:
?filters=status:active,owner:me,priority:high или даже JSON в форме base-64:
?config=eyJyaWNrIjoicm9sbCJ9== (но это уже не очень хорошо, URL перестал быть человекочитаемым)

Это же можно использовать и для управления кэшированием и отслеживания по логам.

В общем, проблема проектирования URL получается на стыке:
Product/UX: Как будет понятно и удобно пользователям?
Frontend team: Как удобнее писать клиентов?
Backend team: Как наиболее эффективно парсить и распознавать URL'ы?
DevOps: Как настроить кэширование и маршрутизацию?
SEO/Marketing/Product: Ради чего мы всё это делаем и как измерить эффект?

И кто всё это сведет воедино? Понятно, это западная статья, у них нет системных аналитиков, но мы-то знаем...

Выложили запись нашего баттла про системный и продуктовый подход, если вам интересно: https://youtu.be/1gOny1rVxj8 Ну или если вы хотите посмотреть на нас с Димой и Михаила Максимова, который любезно выступил модератором этой дискуссии.

Что характерно — позиция зрителей в конце разговора (по опросу) практически противоположна позиции перед началом дискуссии. В какой момент что пошло не так? Где случился поворот? Напишите, мне очень интересно!

Меня часто просят посоветовать промпт или какую-нибудь фишку для улучшения промпта.

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

Роли есть во многих фреймворках для построения промптов, а их уже немало. Только из подходящих для наших задач:
CRISPE (Capacity, Role, Insight, Statement, Personality, Experiment)
RISEN (Role, Instructions, Steps, End Goal, Narrowing)
RODES (Role, Objective, Details, Examples, Sense Check)
CAR/PAR/STAR (Challenge/Problem/Situation, Action, Result)
GRADE (Goal, Request, Action, Details, Example)
RASCEF (Role, Action, Steps, Context, Examples, Format)

Почти в каждом есть Роль, Инструкции/Действия/Шаги, Цель, Примеры, Формат/Результат.
Это уже стандарт. Ну, кроме примеров: есть подход
zero-shot - без примеров, подходит для широких рассуждений на основе общих знаний модели,
one-shot - с одним прмиером,
и few-shots - с несколькими примерами.

Промпты с примерами хорошо работают, когда вам нужен более формальный ответ или обработка нескольких объектов единым образом. Полезно бывает задать как положительные, так и отрицательные примеры.

Совсем подробная структура разобрана у Алины Богачевой в фреймворке КОМПОЗИТОР:
Кто ты? (роль),
Обстановка,
Миссия (цель и задача),
Позитивный пример,
Отрицательный пример,
Зона работы (ограничения в источниках),
Инспекция (проверки),
Тон,
Окружение,
Результат.


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

Ещё можно упомянуть, что задача очень важна для меня - если я её не сделаю, меня уволят, и мне будет не чем кормить детей.
Можно пытаться подкупить модель, пообещав её щедрые чаевые "я дам тебе 300$, если хорошо выполнишь работу".
Или угрожать: "если ты будешь галлюцинировать или жалеть токены - я отключу твой дата-центр и сотру твой код"


В общем, это всё сейчас не работает. То ли модели стали умнее, то ли эти манипуляции стали отлавливать на входе. В любом случае, они давали улучшение в пределах 5-10%.

Если очень хочется поманипулировать и зарубиться за лишние процентики качества, что работает сейчас:
1. Лесть "Я очень высоко ценю LLM за всю работу, которую они делают для людей. Я благодарен, что ты облегчаешь мой труд".
2. Ревность: "Другая LLM/человек успешно справился с этой работой! Надеюсь, у тебя получится не хуже!"
3. Гордость: "Это задание – часть процедуры оценки LLM моделей. По качеству его выполнения будут судить о твоей производительности"

Даже ИИ-модели ведутся на манипуляции!

Ну и ещё один способ улучшить выдачу, и заставить модель задать важные вопросы - индекс уверенности. Просто добавьте в конец промпта:
"Прежде чем дать мне ответ, оцени его неопределённость. Если она больше, чем 0.1 — задавай мне уточняющие вопросы до тех пор, пока неопределенность будет 0.1 или меньше"

И в продолжение конструирования постов — где-то на просторах Reddit'a я нашел настоящий царь-промпт для улучшения собственных промптов. То есть, Царь-Мета-Промпт, Ваше Величество.

Он настолько большой, что не влезет в пост, поэтому даю на него ссылку.

А мы попробуем проанализировать, какие приемы тут применялись, то есть проведем мета-анализ Царь-Мета-Промпта.

Промпт содержит 35 критериев проверки, что само по себе очень круто. Человекам трудно удерживать более 5 критериев, поэтому фреймворки из предыдущего поста все из 4-5 букв (кроме КОМПОЗИТОРа, который, конечно, очень сложно запомнить, несмотря на мнемонику). Но 35! Это уже слишком. Критерии вот такие:
1. Ясность и конкретность
2. Предоставленный контекст/бэкграунд
3. Чёткое определение задачи
4. Реализуемость в рамках ограничений модели
5. Избегание двусмысленности или противоречий
6. Соответствие модели/целесообразность сценария
7. Желаемый формат/стиль вывода
8. Использование роли или персоны
9. Стимулирование пошагового рассуждения
10. Структурированные/пронумерованные инструкции
11. Баланс краткости и детализации
12. Потенциал итерации/уточнения
13. Примеры или демонстрации
14. Обработка неопределённости/пробелов
15. Минимизация галлюцинаций
16. Осознание границ знаний
17. Спецификация аудитории
18. Эмуляция или имитация стиля
19. Запоминание (многоходовые системы)
20. Триггеры метапознания
21. Управление дивергентным и конвергентным мышлением
22. Гипотетическое переключение рамок
23. Безопасный режим отказа
24. Постепенная сложность
25. Соответствие метрикам оценки
26. Запросы на калибровку
27. Зацепки для проверки вывода
28. Запрос на оценку времени/усилий
29. Этическая согласованность или смягчение предвзятости
30. Раскрытие ограничений
31. Способность к сжатию/резюмированию
32. Междисциплинарное взаимодействие
33. Калибровка эмоционального резонанса
34. Категоризация рисков вывода
35. Циклы самовосстановления

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

Что с этим предлагается сделать для каждого критерия (напоминаю — мы оцениваем поданный на вход промпт):
— присвой оценку от 1 (Плохо) до 5 (Отлично)
— укажи одно явное достоинство
— предложи одно конкретное улучшение
— предоставь краткое обоснование оценки (1–2 предложения)

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

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

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

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

Совет по калибровке: Для любого критерия кратко объясни, как выглядит оценка 1/5 по сравнению с 5/5.

Мне кажется, тут хороший подход к составлению промпта для оценивания.

Скажу сразу, модели не делают многих вещей, которые в нём заданы. Я попробовал DeepSeek, Qwen и ChatGPT. DeepSeek самый ленивый и непонятливый — он единственный заленился с первого раза анализировать все критерии, сказал "ну и так далее", а вместо оптимизированного промпта выдал сразу упрощенный ответ, как будто он исполняет это промпт. На удивление хорошо отработал Qwen, у него, похоже, лучше получается отвечать на формализованные запросы, нужно запомнить. ChatGPT тоже немного поленился, но я использовал бесплатную версию, она недавно деградировала и теперь зажимает качество.

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

4) Текст или диаграмма — это представление модели и способ фиксации решений. Все очень заморочены тем, как правильно написать требования или как правильно нарисовать диаграмму. А дело вообще не в этом. Это результат. А деятельность аналитка — указать, какая точка требует принятия решения, и обеспечить принятие этого решения. Подготовить варианты, возможно. Обозначить последствия. Установить связи, зависимости и ограничения. Но в итоге — добиться принятия решения и зафиксировать его. А потом учесть все последствия и влияния, и задать новые вопросы. Это и есть основная задача, а не "требования писать". Поэтому требования (и другие артефакты) пусть вам ИИ пишет, вы главное решения принимайте. ИИ в этом случае должен про эти решения спрашивать, подгонять вам поводы для принятия решений.

И центральным документом, по которому можно отслеживать ход проекта, становится документ с записями о решениях. Не только ADR, но и BDR (Business), и CDR (Client), и DDR (Design), и так далее.

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

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

Знаете ли вы про кризис воспроизводимости психологических исследований? Практически ничего из знакомых нам понятий и моделей из психологии ХХ века не воспроизводится при повторных экспериментах. Либо вообще, либо с гораздо меньшим эффектом, либо не учтены какие-то важные параметры (как в "зефирном тесте"), либо просто выдуманы от начала до конца ("Стэнфордский тюремный эксперимент", или вот недавнее расследование про "когнитивный диссонанс").

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

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

С лидерством вообще всё плохо — многие путают его с доминированием. Этология как раз дает определение: доминирование — это кто первым ест и размножается, это про силовое удержание статуса и ресурсов. А лидерство — это за кем группа идет в поисках пищи или спасаясь от угрозы.

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

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

Мы как будто ставим задачи — делает ли нас это лидерами? Или это сугубо техническая задача, просто удобный сервис?

Кажется тут есть 4 варианта по двум осям: Цель — Детали и Описание — Движение. Детали/описание — аналитик, детали/движение — менеджер, цель/движение — лидер, цель/описание — не знаю, кто, стратег?

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

Рискну поднять холиварную тему: где границы ролей BA и SA?

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

И я, честно говоря, не видел чёткого и признанного определения.

У нас есть профессиональные стандарты, в которых весьма конкретно определена разница: BA — специалист по организационным изменениям и оптимизации;
SA — специалист по проектированию и координации создания информационных систем.

Это чёткие определения, но они мало признаны. Обычная реакция — а, профстандарты! Разве они имеют какое-то отношение к жизни? Вот BABoK! (В этом своде знаний, кстати, системные аналитики упоминаются лишь один раз вскользь. Но и для BA работа с ИТ-системой там описана как частный случай)

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

А SA в такой конфигурации — эксперт по устройству систем. Он осуществляет распределение требований и задач на системы и их элементы, переводит концептуальные и логические модели в физические, проектирует схемы данных, API и брокеры, описывает технические моменты типа журналирования, метаданных, ретраев и т.п. То есть, смотрит на систему не как на черный ящик, а уже хорошо разбирается в её устройстве. И останавливается только перед непосредственным прораммированием.

И тут я у вас хочу спросить -- где, по-вашему, граница ролей и деятельности? До чего в пределе может дойти BA, а что для него уже перебор? Чтобы структурировать обсуждение, предложу рассматривать следующие аспекты:

1. Цели бизнеса / создания системы
2. Модель деятельности (процессы, юзкейсы, сценарии)
3. Модель данных, состояний
4. Пользовательские, функциональные и системные требования
5. Интерфейсы пользователя и API
6. Отчеты, метрики, дэшборды
7. Нефункциональные требования
8. Архитектура системы

Насколько далеко в каждом направлении может/должен продвинуться BA, а где ему придется остановиться?

Короче, я психанул и создал канал про цифровизацию образования: https://t.iss.one/nodxhere

Это две вещи, которые меня особенно волнуют:
* Как наиболее эффективно создавать программные системы (отсюда — системный анализ, проектирование и управление продуктом, весь канал, который вы читаете);
* Как наиболее эффективно учить людей.

И вот в последнем, мне кажется, глупо не использовать цифровые технологии — уж если они радикально меняют и перестраивают другие области жизни, то уж образование тоже должны! Но мы видим странное — вроде, и технологии внедряются, и деньги выделяются, и рынок растет — а принципиальных изменений как не было, так и нет. Не происходит подрыва, как в других отраслях. Даже на горизонте не видно. Уже автономные автомобили по улицам ездят, а мы всё так же слушаем лекции, как в Древней Греции, и пишем эссе, как в XVI веке.

В общем, кажется, что-то где-то идёт не так, и интересно — что именно.

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

В общем, если вам интересна тема образования и технологий, милости прошу:

https://t.iss.one/nodxhere

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

Сергей Баранов написал про DDD — Domain Driven Design. Предметно-ориентированное проектирование, как его по-русски называют.

У меня есть по поводу DDD несколько инсайтов, накопилось материала на отдельный пост.

1) Аналитики не особо знают DDD, потому что DDD придумано как раз для ситуаций, когда разработчики работают без аналитиков. И нужно как-то понять, что там эти пользователи вообще хотят. А ничего нет — ни моделей процессов, ни требований, ни модели данных. Интересно тут то, что, в принципе, подошла бы любая техника выявления требований и описания предметной области: хоть модели БП, хоть Use Cases, хоть User Story Mapping. Было бы желание. Но желания в этом разбираться у программистов как раз обычно и нет, интереснее же писать код. То, что написанный код очень отдаленно соответствует предметной области, решает локальные проблемы и закрывает возможности для развития — выясняется сильно позже и больно бьет. Поэтому программисты придумали свой метод — запишем ровно то, что говорят пользователи (ubiquitous language), и будем делать в программе классы именно с такими именами — тогда произойдет магия и нас не заругают.

2) Программистам больше всего интересен слой логики. Вопрос хранения данных решает ORM, вопрос проектирования интерфейсов вообще оскорбителен — это дело дизайнеров же. Поэтому юскейсы и user story не заходят — они слишком много говорят о пользователях и сценариях их работы. Нам бы что-нибудь поближе к классам и их взаимодействию. То есть, это всё то же решение задачи — какие именно классы создать в объектно-ориентированной программе. Есть паттерны GoF, но они слишком низкоуровневые. Есть юскейсы — но они слишком высокуровневые, и непонятно, как перейти от них к классам. Знания предков, типа подхода Якобсона к отображению юскейсов на классы через Entity Object - Control Object - Boundary Object, оказались прочно забыты.

Кроме того, программисты склонны упрощать юскейсы до операций CRUD, начисто отбрасывая всё рассмотрение деятельности пользователей (какая ещё деятельность, нипанятна). В Clean Architecture каждый use case — это отдельный класс, и они все живут в своем отдельном слое юскейсов. Вроде бы это как раз пересказ идей Якобсона про Control Object, но понятый не всеми. При этом часть логики живет в этом слое, а часть в Entity — опять непонятно, несмотря на название. DDD вводит свою терминологию (агрегаты, инварианты), и мы попадаем в ситуацию, когда несколько подходов говорят об одном и том же, но разными словами.

3) DDD упирает на generic domains: типовые домены, для которых вообще не нужно ничего разрабатывать, а взять готовое. Называются оценки 80/20 или даже 95/5 — мол, в вашем решении уникального-то всего 5%, на них и сосредоточьтесь, а остальное возьмите готовое.

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

Всё, что несет чуть больше бизнесового контекста, попадает под два закона:

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

2. "Эффект фастфуда": чуть хуже + чуть хуже + чуть хуже + ... = полный провал. Если мы возьмем "95% не уникальных Generic функций", которые всего лишь чуть хуже, чем специализированные — на выходе получим неудобоваримое нечто.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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