Говорят, что можно бесконечно смотреть на огонь, наблюдать за тем, как работают другие, а также изучать DDD (Domain Driven Design, предметно-ориентированное проектирование). Но если у вас есть только 10 минут — можно прочитать эту статью и пройтись по самым верхушкам, а потом с умным видом кивать головой во время светской беседы.
Покрутили и рассмотрели DDD с разных сторон вместе с Андреем Ратушным — техническим директором компании Югорские Интернет Решения.
О компании: Югорские Интернет Решения — компания, которая занимается автоматизацией бизнес-процессов в коммерческом и государственном секторах. Расположены в г.Ханты-Мансийске. В разработке 12 человек.
1. Что такое DDD, можно объяснить даже ребёнку (или маркетологу)
DDD — это подход, который нацелен на изучение предметной области предприятия в целом или каких-то отдельных бизнес-процессов. Это отличный подход для проектов, в которых сложность (запутанность) бизнес-логики достаточно велика. Его применение призвано снизить эту сложность, насколько возможно.
Вне подхода DDD, когда программист пишет код, больше внимания он уделяет технологиям и инфраструктуре, например, как отправить сообщение, как его получить, закодировать, сохранить в базу данных, в какую именно базу данных.
Подход DDD говорит о том, что всё это, конечно, важно, но вторично. Бизнес главнее и должен стоять на первом месте. И чтобы вся эта штука заработала вместе, DDD учит нас (разработчиков) разговаривать с бизнесом на одном языке. Не на языке программирования, а на языке бизнеса. Это называется в DDD Единый язык (Ubiquitous language).
2. Фишка DDD — Ограниченный Контекст (Bounded Context)
Ограниченный Контекст (Bounded Context) — ключевой инструмент DDD, это явная граница, внутри которой существует модель предметной области. Она отображает единый язык в модель программного обеспечения. Именно на основании контекстов можно разделить код на модули/пакеты/компоненты таким образом, чтобы изменения в каждом из них оказывали минимальное (или нулевое) влияние на других.
Для разработчиков такой подход позволяет вносить изменения в код не опасаясь, что где-то в другом месте что-то сломается (например, менять что-то в кассе и не переживать, что из-за этого что-то отвалится у курьеров).
Для тимлидов такой подход позволяет в значительной степени распараллелить работу команд(ы), что может значительно ускорить работу по проекту.
Кроме ограниченного контекста есть ещё всякие штуки типа карт контекстов, единого языка, отношений между контекстами, карты трансляций… уффф! Об этом за 10 минут не расскажешь, но можно почитать «зелёную» книжку.
3. Главные книжки по DDD: красная, синяя и зелёная
DDD — довольно старый подход. Его использование выглядит разумным и вполне оправданным, но почему-то он всё ещё мало распространён, про него мало говорят на конференциях. Да что не так с этим DDD?
Есть предположение, что основная проблема в дефиците учебных материалов. Вся теория описана в нескольких книжках: красной, синей и зелёной. Говорят, что есть «ещё одна красная книжка», но её пока мало кто видел :)
Красная и синяя книги настолько тяжелы в восприятии, что где-то на середине хочется вышвырнуть книгу в окно с криками: «Хватит с меня этого дерьма, нафиг этот непонятный DDD! Пойду, сделаю как умею». И это только про теорию, с материалами по практике ещё сложнее.
Поэтому, если вы всё-таки решите начать изучать литературу по DDD, то лучше всего начать с «зелёной» книги. В ней Вон Вернон пробегается по верхушкам подхода и на простых примерах показывает его преимущества. Говорят, что перевод получился сомнительным, так что лучше читать в оригинале.
4. Как понять, что пора применять DDD
Посчитайте количество сценариев использования вашей системы. Если их в районе 10-15, значит бизнес-логика не такая сложная, и вы можете не париться, никакого DDD не применять.
Если у вас 30-50 и более UX-кейсов, и они очень сильно пересекаются, имеет смысл задуматься над применением DDD хотя бы в какой-то части системы.
5. Как внедрить DDD в компании снизу вверх
Представим, что вы разработчик, которому нравится DDD, и вы думаете, что в вашей компании этот подход можно применить, чтобы причинить людям счастье.
Начинать партизанское внедрение DDD одному тяжело. Во-первых, знаний может оказаться недостаточно, чтобы запустить процесс. Во-вторых, чуваки из вашей команды могут подумать, что вы занимаетесь глупостями и всё поломают, напихав палок в колёса.
Лучше начинать внедрение с создания инициативной группы: вместе попробовать подход, понять нюансы, разобраться на практике.
Уже потом можно пойти к архитектору или техдиру, чтобы объяснить ему ценность. Но помните, что DDD нужен не везде. DDD решает конкретные задачи, поэтому очень важно не перестараться.
У подхода есть побочное действие: если люди начнут хотя бы стремиться к DDD, то они уже начнут действовать в парадигме «Разделяйте, делите, понижайте связность и следите за бизнес-логикой». А от этого начнутся положительные изменения: где-то код будет лучше писаться, где-то скорость увеличится. Не обязательно эти знания должны превратиться в коде именно в контексты и другие DDD-шные артефакты. Код может остаться кодом, но он станет лучше, а скорость и качество повысятся.
6. Как внедрить DDD в компании сверху вниз
- Убедиться, что этот подход поможет в конкретном случае.
- Найти человека в команде, у которого есть архитектурные навыки (он будет помогать определить, где в системе швы, по которым надо резать).
- Пригласить практиков DDD, чтобы они вас научили.
- Пошагово отрефакторить необходимые части системы. Помните! Далеко не все части нуждаются в подобном рефакторинге. Выделение моделей и переработка кода необходима только там, где бизнес получит от этого максимальную выгоду.
7. Как научить человека DDD без его ведома
Конечно же, через практику. Просто не говорите человеку заранее, что учите его DDD, не пугайте раньше времени.
Пусть человек приходит и получает задачки. Не говорите ему, что это DDD, пусть просто делает. Он сделает, исходя из того, как он понимает солиды и всё такое. Потом, когда он будет сдавать работу, ему нужно сказать: «Дорогой чувак, оно вроде работает, но его нужно переделать», — и объясняете ему почему.
Не заставляйте читать или учить всё целенаправленно. Будьте интерактивными в этом плане. Так человек за 3-5 месяцев начнёт понимать базовые принципы DDD: с точки зрения реализации, с точки зрения теории. Паттерны он начнёт понимать ещё раньше по артефактам подхода – картам контекстов. Сначала людям будет ничего непонятно, но постепенно они врубятся, а некоторые даже книжки начнут читать.
8. Умею DDD — неважная строчка для резюме в России
Если вы находитесь в России и знаете DDD — это круто. Но далеко не факт, что сами знания DDD пригодятся в работе. Скорее, это будет служить индикатором для работодателя о вашем высоком уровне развития как разработчика. Ведь навыки, которые вы приобретаете, изучая подход DDD, развивают вас как программиста и как проектировщика (архитектора).
А вот если вы задумываетесь о переезде за границу, то такая строчка в резюме может оказать положительное влияние. За границей DDD-комьюнити намного больше, и сам подход намного популярнее, чем у нас. Особенно в Европе.
9. Связь DDD с волосами на лице
Наблюдение: люди, которые разбираются в DDD, носят бороды. Значит ли это, что наличие бороды — предпосылка к успешности в DDD? Вы как считаете?
10. Полезные материалы по DDD
- Microsoft про DDD
- Поваренная книга Ruby-разработчика: Domain Driven Design рецепты (1 часть, 2 часть, 3 часть, 4 часть, 5 часть)
- Обзорная статья про стратегическое проектирование
- Просто куча всего на тему DDD
- DDDevotion cообщество в Телеграме
- DDDevotion группа в Фб
Подкаст «Ничего такого». Дорогой читатель, эта статья была написана под впечатлением от выпуска нашего подкаста. Нам стало интересно как выглядит культура, строятся команды и процессы в разных технологических компаниях вроде Miro, Яндекса, Amazon, Microsoft, Едадила. Поэтому мы встретились с ребятами оттуда и поболтали на эти темы.
Сейчас его можно послушать:
- SoundCloud
- Apple Podcasts
- Яндекс.Музыка
- Spotify
- Или скачать в нашем канале в Telegram.
Автор: Борис
