Кто я и зачем всё это
Всем привет! Меня зовут Бодров Иннокентий. Я — продакт, аналитик и архитектор с более чем 17-летним опытом в разработке информационных систем, построении успешных продуктов в телеком-индустрии, финтехе, электронном документообороте и корпоративных порталах.
Последние несколько лет я активно продвигаю идеи работы на основе здравого смысла, бережливости и современного, гибкого (в хорошем смысле слова) продуктового подхода. И один из инструментов, который мне помогает в этом — это Domain-Driven Design (DDD).
Многие считают DDD чем-то исключительно для разработчиков. Я же уверен: это прежде всего коллаборативная техника. Она полезна аналитикам, продактам, архитекторам, менеджерам. Но особенно важно, чтобы в DDD погружались те, кто ближе к бизнесу. Потому что именно у них есть шанс выстроить мост между миром предметной области и кодом.
О том, как это сделать — и будет эта статья.
Когда вы, системный или бизнес аналитик, продакт или проджект, видите в описании «Domain‑Driven Design» (DDD), может показаться, что это что‑то «не про нас» — скорее для архитекторов или разработчиков. Но, как показывает практика, именно системный или бизнес‑аналитик часто оказывается тем самым проводником между предметной областью и кодом. И вот здесь DDD начинает играть ключевую роль.
В этой статье — по мотивам живого занятия с аналитиками — разберём:
Что такое DDD и зачем он нужен в реальных проектах
Как договориться о «едином языке» с командой и заказчиком
Что такое ограниченный контекст и зачем его выделять
Как устроена архитектура с точки зрения DDD
Почему знание кода важно для аналитика
Как провести анализ субдоменов на примерах ресторана и образовательной платформы
Какие книги и ресурсы помогут погрузиться в тему глубже
Что такое Domain-Driven Design и зачем он нужен
DDD (предметно-ориентированное проектирование) — подход, предложенный Эриком Эвансом, который помогает создавать архитектуру и код, отражающие реальную предметную область. В его основе лежат четыре главных направления:
Стратегическое проектирование — как разобраться в сложных предметных областях и выделить в них ключевые элементы
Командная работа — выстраивание общего языка между аналитиками, бизнесом и разработчиками
Архитектурные подходы — принципы проектирования систем, компонентов и интерфейсов
Тактические паттерны — работа с сущностями, агрегатами, репозиториями и сервисами
DDD особенно ценен там, где система сложная и классическая автоматизация уже не справляется. В условиях цифровых продуктов с высоким уровнем неопределённости, DDD помогает снизить хаос и выстроить понятную модель взаимодействия.
Кроме того, он позволяет сократить количество недопониманий между участниками команды. Когда все говорят на одном языке и используют одни и те же определения, исчезают десятки мелких и крупных конфликтов.
Единый язык: основа командного взаимопонимания
Один из главных принципов DDD — это ubiquitous language, или единый язык. Это общий словарь, на котором разговаривают бизнес, аналитики, архитекторы и разработчики. Такой язык помогает устранить расхождения в понимании даже самых простых терминов.
Например, "клиент" в разных департаментах может означать:
Тот, кто написал в чат (для поддержки)
Тот, кто зарегистрировался (для backend-команды)
Тот, кто открыл счёт (для compliance)
Тот, кто провёл первую транзакцию (для бухгалтерии)
Если не договориться, что именно мы называем "клиентом" в конкретной части системы, недоразумения неизбежны. Поэтому фиксация терминов и определений — обязательный шаг на старте работы над любым модулем или продуктом.
DDD предлагает оформлять словарь, использовать его в требованиях и поддерживать в актуальном состоянии.
Как код может отражать предметную область
DDD влияет не только на бизнес-логику, но и на сам код. Его цель — сделать код "говорящим".
Вот пример на C#:
var discount = CalculateDiscountBy(customerId);
order.ApplyDiscount(discount);
order.SetStatus(OrderState.AwaitingPayment);Такой код гораздо понятнее, чем:
var d = Calc(1);
o.StateId = 1;Это позволяет даже не разработчику разобраться, что делает функция. Именно поэтому важно, чтобы аналитик не просто передавал требования, но и помогал формировать язык домена, который ляжет в основу кода.
Ещё один любопытный пример — 1С. Есть большое подозрение, что популярность этой системы во многом обусловлена тем, что в коде 1С с самого начала использовались термины, понятные специалистам предметной области. Бухгалтер мог посмотреть на код и понять, что в нём происходит. Более того — иногда даже поправить что-то или пояснить разработчику без участия аналитика. Это давало возможность дешевле, проще и быстрее адаптировать продукт под конкретные процессы. Был ли это осознанный DDD или нет — вопрос открытый, но подход, безусловно, попал в точку. Именно поэтому важно, чтобы аналитик не просто передавал требования, но и помогал формировать язык домена, который ляжет в основу кода.
Практика: как понять простые вещи по-разному
На лекции мы разобрали простой пример: что такое "занятие", "слушатель" и "преподаватель". Участники дали десятки разных формулировок. Кто-то определял занятие как "процесс трансляции", кто-то — как "структурированную лекцию с темой", кто-то — как "период времени с обучающим контентом".
Этот кейс показывает, насколько важно зафиксировать определения даже для простых понятий. Именно для этого нужен глоссарий.
Качественный глоссарий должен быть:
Однозначным (исключает двусмысленность)
Самодостаточным (не требует перехода по ссылкам для понимания)
Без рекурсивных определений (не объясняет "руку" через "рукастость" и обратно)
Ограниченный контекст: у каждого свои значения
Единый язык применим внутри одного ограниченного контекста (bounded context). Это логическая граница, внутри которой термины имеют конкретное значение. DDD прямо указывает: не существует одного языка для всей компании.
В каждом контексте — свои модели, определения и объекты. Один и тот же термин (например, "пользователь") может означать:
Клиента, заполнившего анкету
Зарегистрированного юзера
Активного участника программы лояльности
Эти контексты можно (и нужно) разделять, чтобы избежать конфликта моделей и зависимостей. В монолитной архитектуре это делается через изоляцию модулей, в микросервисной — через отдельные сервисы.
Субдомены: core, supporting и generic
DDD выделяет три типа субдоменов:
Core domain — главный бизнес-домен, дающий конкурентное преимущество. Здесь нужна гибкость и высокая вовлечённость команды. И важно помнить: core-домен не обязательно один. Это может быть несколько направлений, которые составляют УТП (уникальное торговое предложение) компании — то, на чём она зарабатывает деньги, её ноу-хау. Именно поэтому передача core-домена на аутсорс — это очень рискованное решение. Известны случаи, когда компания делала ставку на внешнего подрядчика для разработки основного функционала и в итоге получала сильную зависимость от конкретного вендора. Либо сталкивалась с болезненным и дорогим переходом. Потому что всё равно внутренняя экспертиза в этих ключевых вещах должна быть — никто извне не сможет так точно оценить бизнес-ценность, как сама компания.
Supporting domain — поддерживающий функционал, важный, но не уникальный. Его можно автоматизировать частично или использовать готовые решения. Тут всё чуть тоньше: часть функций может быть очень специфичной для вашей отрасли — такие блоки имеет смысл разрабатывать внутри. А часть, наоборот, легко докупается в виде готовых решений (например, CRM — HubSpot, Salesforce, Битрикс). Их можно взять и адаптировать под свой процесс. Главное — понимать, где проходит граница между уникальным и универсальным.
Generic domain — типовые компоненты, которые не зависят от специфики бизнеса. Лучше купить или взять как сервис (например, бухгалтерия, документооборот, рассылки). Нет смысла пилить свою бухгалтерскую систему, если вы просто используете её как базовый инструмент учёта.
Важно: core-домен нужно разрабатывать внутри команды. Он — ваша уникальность. А generic — не тратить ресурсы и отдать на аутсорс. А вот в supporting — разумно комбинировать: где-то купить, где-то доработать, где-то развить своё.
Кейсы: образовательная платформа и ресторан
Кейс 1: онлайн-курс
Core: преподаватель, занятие (контент и подача)
Supporting: платформа, расписание, личный кабинет
Generic: Zoom, система оплаты, регистрация
Кейс 2: ресторан
Core: меню, техкарты, заказы
Supporting: CRM, склад, программа лояльности, учёт
Generic: бухгалтерия, Zoom-доставка, оплата, поиск поставщиков
Как контексты взаимодействуют друг с другом
DDD предлагает шаблоны взаимодействия контекстов:
Shared Kernel — общий код или модель, разделяемая между контекстами
Customer-Supplier — один контекст зависит от другого, использует его API
Published Language — открытая схема взаимодействия (например, JSON-схема)
Anti-Corruption Layer — прослойка между контекстами, защищающая от «загрязнений» модели
Separate Ways — отсутствие связи между контекстами
Эти шаблоны позволяют системам развиваться независимо, снижать связность и повышать масштабируемость.
Что делать аналитику: инструменты и шаги
Аналитик в контексте DDD — это связующее звено между бизнесом и разработкой. Вот что действительно важно делать:
Завести и вести глоссарий — фиксировать все ключевые термины, которые всплывают в общении с бизнесом и командой. Главное — не пытаться описать всё на свете. Глоссарий должен быть ограничен контекстом, в котором вы работаете. Он может пересекаться с глоссариями других команд, но его задача — обеспечить единый язык именно внутри вашей команды. Все участники — от аналитиков до разработчиков и продакт-менеджеров — должны понимать термины одинаково. Глоссарий может и должен эволюционировать по мере развития проекта.
Использовать термины домена последовательно — особенно в документации, переписке, созвонах. Это может встретить сопротивление — люди будут хотеть использовать старые названия или личные сокращения. Нужно мягко, но настойчиво встраивать доменную лексику: называть вещи так, как вы договорились. Если термин не приживается — обсуждать, переименовывать, договариваться с бизнесом и пересогласовывать. Это нормально. Главное — чтобы всё было прозрачно и согласованно.
Создавать и поддерживать информационные модели — аналитик — это тот, кто первым фиксирует появление новых понятий и их взаимосвязей. Именно он может донести изменения из бизнеса в разработку. Эти модели могут быть выполнены в виде диаграмм классов, ER-диаграмм, схем в Miro или draw.io — главное, чтобы они были полезны команде. Такие схемы можно и нужно использовать для синхронизации с другими командами, чтобы понимать, где и как вы пересекаетесь.
Помогать разработке писать читаемый код — аналитик не обязан писать код, но должен уметь его читать. И если код написан на языке домена, он станет понятен и аналитику, и другим членам команды. Если вы не можете понять, что делает код, возможно, в нём стоит что-то улучшить: нейминг, структура, читаемость. Это зона для совместной работы с архитекторами, разработчиками и другими аналитиками. Не бойтесь влезать в обсуждение.
Контролировать терминологию в проекте — следить за тем, чтобы термины использовались корректно и последовательно. При этом полезно сопоставлять терминологию вашей команды с другими доменами. Например, вы называете сущность "договор", а смежная команда — "контракт". Это нормально, если вы понимаете, что это одно и то же. Такие соответствия стоит фиксировать в виде маппинга между контекстами. Это помогает интеграции, снижает количество ошибок и облегчает синхронизацию.
DDD — это не разовая акция, а культура работы, не революция, а эволюция. И аналитик здесь играет ключевую роль в её становлении и поддержании. Сначала вы просто начинаете говорить в команде на одних терминах. Потом эти термины проникают в требования и модели. Потом — в код.
Что читать и смотреть
Книги:
Vaughn Vernon — "Domain-Driven Design Distilled" (основы)
Vaughn Vernon — "Implementing Domain-Driven Design" (глубже и системнее)
Eric Evans — "Domain-Driven Design" (классика, местами тяжеловата)
Vlad Khononov — "Learning Domain-Driven Design" (современно и практично)
Доклады:
Сергей Баранов — про словари, субдомены и архитектурное мышление
Евгений Пешков — DDD глазами разработчика
Катя Лысенко — "Вначале было слово - архитектура от словаря" (о терминах и понятиях в архитектуре)
В завершение
Domain-Driven Design — это не только про код. Это про понимание, структуру, договорённости и мышление. Это способ справляться со сложностью в цифровых продуктах.
Для аналитика DDD — это инструмент, с помощью которого можно говорить с командой на одном языке, формировать понятную модель и быть уверенным, что продукт отражает реальность.
Начинайте с малого: заведите глоссарий, обсуждайте термины, уточняйте контексты. Вода камень точит. И вы удивитесь, насколько лучше начнут понимать вас — и друг друга — все участники команды.
Если вы хотите задать вопросы, продолжить дискуссию или поделиться своим опытом — забегайте в телеграм канал. А если захотите глубже изучить тему, приходите на открытые вебинары, подписывайтесь на канал и следите за анонсами.