Learning Domain-Driven Design — глава 3

Вова хвалит таблицу в конце главы про эвристики — впервые видит дерево решений именно для тактических паттернов, хотя сомневается, что с ним можно прийти в команду и просто ткнуть в нужную ветку: Влад сам пишет, что это не стопроцентная истина, а точки отсчёта. Илье нравится критика ответа «it depends»: вместо «вот подходы, применяйте по ситуации» автор даёт нежёсткое правило, которое можно нарушать. Александр видел схемы посложнее — карту с полусотней шаблонов, от бизнесовых до технических, — и считает, что ценность не в картинке, а в том, что прочитанное встаёт на места: понятно, где точки принятия решений. Поэтому решения стоит записывать вместе с причинами — какой поддомен, какая ситуация с агрегатами, — чтобы через полгода было видно, что изменилось и пора ли пересматривать; и никогда не обосновывать выбор фразой «так написано в книге», иначе, шутит Вова, коллеги постучат этой книгой по голове.

Илья дополняет стратегией тестирования, которая появляется только здесь: пирамида, ромб и перевёрнутая пирамида — доли unit-, интеграционных и end-to-end тестов для разных видов бизнес-логики. Александр рассказывает, как читает книги: строит собственные деревья решений и сверяет с авторскими, а в статье про выбор мобильной технологии в 2021 году рисовал похожее дерево из вопросов «что нужно, кто есть в компании, куда идёте»; Илья по каждой главе рисует mind map. Про размер ограниченного контекста автор отвечает «конечно, зависит», но добавляет: размер — последний критерий, а начинать стоит с широких границ, складывая в один контекст core-поддомены, которые часто меняются вместе, и generic рядом с ними. Александр напоминает почему: ядро сложное, его логика неявная — копаешь и проваливаешься, как Алиса в нору, — а мелко нарезанные контексты потом очень тяжело объединять.

Глава про эволюцию, по словам Александра, не столько архитектурная, сколько про бизнес: четыре типа изменений — в бизнес-домене, организационные, в знании домена и рост. Поддомены переходят из типа в тип: supporting может стать core, как AWS у Amazon, а core — деградировать в generic, как навигация Garmin после смартфонов и Google Maps; следом приходится менять и тактический паттерн. Переход от Transaction Script к Active Record прост, а от Active Record к доменной модели расписан по шагам: найти value objects, сделать сеттеры приватными, чтобы компилятор показал места изменений, перенести логику в метод агрегата, внешние агрегаты подключать по ссылке и решить, где нужна строгая консистентность. Сигнал к переходу — дублирование логики изменений в разных местах. От доменной модели к event-sourced два пути: сгенерировать приблизительную историю фейковыми событиями или записать одно событие миграции с текущим состоянием; Александр за второе — прозрачность лучше уверенности, — хотя честно вспоминает, как хотел распечатать и сжечь код системы, которую выкинул через два года.

Организационные изменения: партнёрство между командами рассыпается, когда они разъезжаются на удалёнку, и его меняют на customer–supplier; большая команда делится на кредитные и дебетовые продукты, общий бэклог расходится, и интеграцию контекстов приходится разводить. Переход к separate ways уместен для generic и supporting — иногда дешевле взять решение с рынка, чем оставаться заказчиком у внутреннего поставщика; Илья вспоминает, как кредиты разделили на малый и средний бизнес и написать своё оказалось дешевле поддержки общего. Александр видит здесь закон Конвея: меняется структура коммуникации — меняется дизайн. Знание домена — аргумент за широкие контексты: команда, поделившая понятный вроде бы домен на микросервисы, обнаружила, что строгая консистентность должна проходить через границы, и после MVP пришлось склеивать сервисы обратно. Рост — признак здоровой системы, но новую логику распихивают по существующим агрегатам, и получается большой ком грязи; инструменты DDD — поддомены, контексты, value objects, агрегаты — служат границами, по нарушению которых видно, что пора чинить.

Алина проводит по EventStorming: мозговой штурм не столько технический, сколько про бизнес, с людьми из разных процессов — дизайнерами, аналитиками, разработчиками; офлайн около десяти человек, онлайн не больше пяти. Нужна большая доска, стикеры разных цветов, маркеры и еда: сессия занимает часы, иногда дни. Шаги: оранжевые стикеры с событиями в прошедшем времени, которые каждый клеит куда угодно; выстраивание таймлайна; розовые ромбики болевых точек; pivotal events как будущие границы контекстов; голубые команды с акторами; политики автоматизации, когда команду запускает не человек, а система; зелёные read models; внешние системы; затем команды и события группируются в агрегаты — это их публичный интерфейс — и в контексты. Александр добавляет роль фасилитатора: сам он учился этому у популяризатора метода в России, а создатель метода Альберто Брандолини рассказывает его за сорок минут на конференциях; Влад сначала проводит big picture, а потом отдельные сессии по процессам.

Последняя глава разбивает мифы: DDD не только для greenfield — наоборот, больше всего выигрывают brownfield-проекты, если внедрять постепенно, без большого взрыва. Core-домен в legacy находится просто: это код, который все боятся трогать. Александру глава нравится как инструкция технического руководителя в незнакомой компании: понять бизнес, клиентов и конкурентов, выделить поддомены, разобраться, какие тактические паттерны применены и не устарели ли за три года, построить карту контекстов — и оттуда берутся идеи улучшений. Стратегия модернизации — маленькими шагами: сначала логические границы в компонентах и namespace, потом физические там, где нужен свой ритм релизов; тактика — strangler fig, когда новый сервис постепенно перехватывает запросы старого; и продвижение единого языка вплоть до кода. Главный тезис — не DDD ради DDD: бизнес-домен должен драйвить дизайн, а продавать подход лучше на примерах, чем оголтело. Следующий раз — четвёртая часть, а через встречу — разговор с автором.