Learning Domain-Driven Design — встреча с Владом Хононовым

Влад представляется коротко: два года мучился с книгой, в ней всё, что он знает о DDD, а сам подход когда-то изменил траекторию его карьеры. На вопрос слушателя «почему не Эванс» отвечает, что Эванса никто не отменял — это книга на чёрный пояс, и в оригинале её дочитывают с ощущением разблокированной ачивки. Его цель была написать то, что читается за час: так появился отчёт на платформе O'Reilly, восемьдесят страниц, эксклюзив для подписчиков, который печатали как мерч для конференций в Берлине и Нью-Йорке — в Берлине в 2019 году Александр увидел его выступление. Отзывы просили бумагу, издательство потребовало расширить до 160 страниц, получилось 300 — «суп из топора». Книга Эванса одновременно актуальна и устарела: концентрированная мудрость, но без event sourcing, CQRS и доменных событий, и второй редакции не будет. Поэтому книга Влада — для первых поясов, чтобы довести до синего, а за чёрным — к Эвансу.

Про перевод: соглашение с российским издательством подписано, но что с планами — неизвестно. Влад с 1995 года живёт в Израиле, переводить сам не возьмётся и договорился с ребятами из telegram-сообщества DDD, которые живут в этом языке. Александр корректировал перевод Клеппмана, где местами терялся смысл, и хвалит перевод Database Internals Алекса Петрова с участием автора. Про «единый язык» — клуб спорил о переводе ubiquitous на первой встрече, и Влад использует именно это слово по-русски: «вездесущий» создаёт впечатление универсальности, а язык един только в границах контекста. На вопрос «видел ли кто-то DDD здорового человека» Влад отвечает, что слышал на конференциях одно: у нас brownfield, нужно разрешение начальства, пока копим теорию. На практике DDD не чёрно-белый: не нужны CEO с корпоративной стратегией и команда, цитирующая Эванса; чаще встречается замаскированный DDD, к которому людей приводят наводящими вопросами — хотим ли сохранить данные при падении сервера, значит одна транзакция, значит границы поменьше ради производительности.

Вова подхватывает: для greenfield лучше взять максимально широкий контекст и сжимать по мере необходимости; Влад согласен — стартап не знает, что будет делать через полгода, и бросаться в микросервисы с маленькими контекстами — дорога в никуда, безопаснее границы, которые упростят рефакторинг. Илья вспоминает, как сервисы нарезали по кусочку, а через полгода закончился бюджет и все они жили на одной ноде. Александр рассказывает про секции system design на собеседованиях, где сильные кандидаты сами видят проблемы happy path, а других подталкивают вопросами «а что, если», — и про случай, когда технически сильный разработчик нарезал десять сервисов, а потом их склеивали до трёх, чтобы транзакции не прыгали через границы. Александр добавляет пример с грейдами: дерево решений не заменяет понимания, почему решение именно такое. У Эванса, замечает Влад, есть глава об итеративном подходе, затерявшаяся среди остальной мудрости; пример WolfDesk добавлен ради вопросов для самопроверки, которые редакторы предлагали убрать, а компилируемой реализации нет намеренно — но люди попросили, и репозиторий обещает «скоро».

Из онлайн-форматов Влад делал на O'Reilly тренинг DDD для монолитов — четыре итерации по шесть часов — и ценит живое общение, хотя платформа показывает участников только инициалами: «это value objects, коллизии постоянно». Про справочники, которые пользователь редактирует в админке: Вернон определяет их как value objects, но две строки с одним статусом и разными идентификаторами — бессмыслица, а строка вместо типа не даст потом ничего поменять, поэтому Влад моделирует их как entity ради гибкости или заводит машинный код в верхнем регистре и словарь для перевода людям. Инструменты моделирования — Miro, доска и бумага; кодогенерацию применял один раз, для домена с огромным числом событий на C#, и сегодня счёл бы её звоночком: модель слишком сложна и, возможно, скрывает несколько контекстов. Изменение идентификатора агрегата — редчайшее исключение вроде смены номера паспорта; Илья шутит про программу защиты свидетелей.

Чтение чужих данных через специально подготовленную view вместо тривиального REST: чужая база — плохой тон, но если view сделана для интеграции и объявлена контрактом, который не ломается при смене внутренней модели, Влад не видит проблемы — это published language, и в data mesh есть похожий ход. Про сагу и process manager: терминологию он сверял с Крисом Ричардсоном, чтобы говорить на общем языке; сага — паттерн из старой, ещё напечатанной на машинке статьи, process manager — из Enterprise Integration Patterns, и это почти одно и то же: сага рисуется стрелочками между сервисами, process manager несёт отдельный жизненный цикл и сложную логику — «если в саге есть if, это уже process manager». Защитный слой живёт в том же жизненном цикле, что контекст, или выделяется отдельно, когда источник часто ломает интеграцию. Влад вспоминает интеграцию с командой, чей core-домен менялся постоянно, а события доходили не всегда: пришлось совместить события с периодической полной выгрузкой через отдельный API — Александр узнаёт лямбда-архитектуру. Транзакционность между двумя базами означает распределённый агрегат, и правильный вопрос — какой уровень транзакционности нужен, а не как её обеспечить.

О будущем: писать было так тяжело, что Влад зарёкся даже от текстовых сообщений, но контракт подписан сразу на две книги. Вторая — Balancing Coupling in Software Design — про балансировку связанности, требует больше исследований, уже в черновике на ревью и в сентябре, вопреки Amazon, не выйдет. Из рекомендаций — старая книга семидесятых о процедурном программировании, которая изменила его понимание микросервисов, и A Philosophy of Software Design, короткая и фундаментальная. Заключение автора: не воспринимайте DDD как предписание «всё или ничего». Он когда-то писал, что выкинул бы тактическую часть, и от сообщества прилетело, но позиция осталась: ядро DDD — единый язык и ограниченные контексты, а агрегаты и value objects — generic-поддомен, описанный ещё у Фаулера. Влад видел проекты с сотнями агрегатов и репозиториев без всякого DDD и проекты без единого агрегата, где были контексты и язык, — и это был настоящий DDD.