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

Александр представляет автора: он увидел Влада на архитектурной конференции в Берлине в 2019 году, написал конспект по его отчёту, а из отчёта потом выросла книга — вдвое больше по числу глав, с новой частью о сравнении DDD с другими методологиями. Книга начинается с узнаваемой сцены: новичку показывают контроллеры и репозитории, а потом класс с кучей условий и говорят «а вот это бизнес-логика». Александр вспоминает, как в начале карьеры важнее всего казались паттерны, хотя главное в коде — то, что он решает задачу бизнеса, и именно в этом компания отличается от конкурентов. Первая часть книги отвечает на вопросы «что и почему», и, по его словам, одна она способна продвинуть по карьере лучше очередной технической книжки. Дальше Илья разбирает три типа поддоменов — core, generic, supporting — по таблице из конца главы: сложность, частота изменений, где реализовывать, даёт ли конкурентное преимущество.

Пример подбирают простой: у пекарни ядро — сами булочки и то, почему ходят именно сюда; выкладка товара — поддерживающий поддомен со своей, но очевидной экспертизой; зарплаты и подвоз муки — типовые задачи, которые дешевле купить и легко отдать наружу. Илье труднее всего давалась граница между типовым и поддерживающим, пока не встретился пример, что написать контроллер — это поддерживающая работа: снаружи не возьмёшь, а сделать надо. Александр добавляет, что типы не прибиты гвоздями: то, что начиналось как поддержка, при хорошем исполнении превращается в продукт для других, и Вова приводит EPAM с внутренним инструментом Telescope для поиска людей и учёта загрузки, который компания теперь продаёт клиентам. Обратная ловушка тоже названа: быстро собранная админка на типовом решении обрастает доработками, и на общедоступный вариант уже не переключиться. Важное замечание главы — поддомены не проектируют, а находят, часто начиная со структуры компании, что перекликается с законом Конвея.

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

Слово «единый» участники считают неточным переводом ubiquitous и вспоминают «Убик» Филипа Дика — «вездесущий» сильнее. Именно с этим Александр связывает частую ошибку: не дочитав до третьей главы, люди натягивают один язык на всю компанию. Ограниченные контексты он показывает на «заявке»: в кредитах это заявка на кредит, в бизнес-линии — на начало работы с партнёром, в расчётно-кассовом обслуживании — на счёт; а внутри онлайн-привлечения, за которое он отвечает, заявка от короткой формы с именем и телефоном растёт до дозаполненной, проскоренной и лежащей в хранилище со статусами доставки продукта. Унифицировать это — фиаско, а с явными границами и переходами всё работает. Илья добавляет «уловку 22» из книги, два традиционных выхода — одну модель на всё или префиксы — и аналогию с картами: разных карт много, и нужна минимальная модель под задачу, как кусок картона вместо холодильника. Вова видит в этом ту же проблему, что в документировании архитектуры через разные views. Правило команд однозначно: две команды на одном контексте не работают; Александр вспоминает, как однажды ради этого физически распилил монолит.

Четвёртая глава — о взаимодействии контекстов, и Вова начинает с группы партнёрских паттернов: партнёрство как договорённости по случаю, требующие постоянного общения, и общее ядро на примере кредитов Т-Банка, где у привлечения и взыскания разные федеральные законы и каналы, но общая модель клиента, компании и скоринга, которой может владеть третья команда через CRM. Александр расставляет остальные паттерны по балансу сил между поставщиком и потребителем: если сила у поставщика — «бери или уходи», и потребитель либо конформист, принимающий чужую модель, либо ставит защитный слой, переводящий внешнюю модель в свою и оберегающий от совместимых изменений; если сила у потребителя, поставщик становится открытым хостом и публикует язык — дипломатический, свой для разных потребителей.

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