ddd что это значит
Очень технический выпуск: про DDD и проектирование сложных систем
В свежем выпуске подкаста «Сушите вёсла» обсудили методологии проектирования сложных систем. Много говорили о Domain Driven Design, Event Sourcing и CQRS. Тема непростая, но, как говорится, очень интересная.
Артём Кулаков и Рома Чорыев — разработчики Redmadrobot, они записывают подкаст, где обсуждают различные стороны создания ИТ-продуктов. Ниже ссылка на новый выпуск, тайминг и ответы на душещипательные вопросы. Но для начала небольшой дисклеймер:
Почему все больше и больше ведется разговоров о различных аспектах и методологиях проектирования систем? Потому что наши системы стали действительно большими. Чтобы разобраться, как проектировать такие системы, мы позвали Алексея Мерсона — системного архитектора из Karuna. В выпуске попробовали разобраться, что такое Domain Driven Design, как он связан с Event Sourcing и при чем тут CQRS и микросервисы. Снять удалось только первый слой, да и то неравномерно. Но всем, кто хочет начать погружаться в тему, этот выпуск будет несомненно полезен. И обязательно ознакомьтесь с материалами к выпуску.
02:29 — Гость студии Алексей Мерсон и как он начинал;
12:26 — почему сейчас все чаще говорят о DDD;
15:30 — полезная литература о DDD;
23:01 — как начать проектировать систему по DDD;
25:05 — Event storming и Miro;
45:15 — что такое Event sourcing;
55:00 — CQRS и его связь с DDD и Event sourcing;
01:06:10 — с чего начать.
Domain-Driven Design — предметно-ориентированное проектирование. Понятие известно давно, но в последнее время в русскоязычном сообществе о нем говорят всё чаще.
Алексей считает, что возможно, это связано с тем, в Agile-мире запускаются проекты, которые без применения DDD «скатятся в печальное состояние», потому что появится расхождение между предметной областью и реализацией.
В первую очередь Domain-Driven Design — это история о проектировании, и предметная область в нем ставится во главу угла. И основной акцент в этом подходе делается на взаимодействии с бизнесом — с заказчиками ПО и приложений.
Если проще, то бывает, что для решения бизнес-задач «конвейер производства ПО» растягивается, и в конечном счете в реализации решения этих задач могут оказаться совсем не такими, какими задумывались изначально. И вот тут, чтобы не играть в «испорченный телефон», применяется DDD. Его цель — сократить расстояние между бизнесом и разработчиками, чтобы последние максимально точно понимали, что за бизнес-процессы они реализуют.
В студии прозвучал резонный вопрос: «представим, что мы поняли, что у нас сложная система, которую будем делать по DDD и у нас на это даже есть много времени. С чего стоит начать?» Алексей дал несколько советов.
Первое — конечно же, придется стартовать с MVP, то есть с «маленьких кусочков», которые затем будут «разрастаться» во что-то большее. Второе — понять процессы, которые нужно автоматизировать. При этом важно находиться в контакте с теми, кто ставит задачи. Например, с продактами или с кем-то из бизнеса, топ-менеджерами. Дальше — расписать сценарии таким образом, чтобы стал понятен контекст, в котором существуют заданные бизнес-процессы.
И, кстати, многие для этих целей используют системой Event storming — это такой способ собрать разработчиков и бизнес-экспертов в одном месте, чтобы вместе исследовать предстоящую разработку.
В Event Storming собираются все заинтересованные лица и на доске с помощью стикеров выстраивают последовательность событий и тех объектов, которые генерируют эти события. Получается некая визуальная карта, в которой становится понятно, как взаимодействуют различные сущности и как они объединяются в контексты.
DDD также обеспечивает основу для стратегического и тактического моделирования. Стратегическое проектирование позволяет точно определить наиболее важные области разработки на основе бизнес-ценностей. Тактическое моделирование нужно для построения работающей Доменной Модели с использование проверенных в бою строительных блоков и шаблонов.
Три столпа DDD
Domain-Driven Design это подход к разработке программного обеспечения, который сфокусирован на трёх основных принципах:
Единый язык (Ubiquitous Language)
Итак, как найти, изучить и запечатлеть этот особый язык, следующие подсказки помогут вам в этом:
Определение DDD
DDD это не серебряная пуля; как и все в программном обеспечении, всё зависит от контекста. Старайтесь использовать этот подход чтобы упростить ваш Домен (Domain), а не добавляйте сложности. Если разрабатываемое вами приложение ориентировано на работу с данными и ваши сценарии в основном подразумевают CRUD операции (создание, чтение, обновление, удаление), то вам не нужен DDD. Вам всего лишь нужен интерфейс манипуляцией данными в вашей хранилище.
Если в вашем приложении реализует менее 30 сценариев использования (Use Cases), может вам проще использовать фреймворки Symfony или Laravel, для управления всей бизнес логикой.
Однако, если ваше приложение имеет более 30 сценариев использования, ваша система подвержена движению в сторону Большого Комка Грязи (Big Ball of Mud). Если вы точно знаете что ваша система будет достаточно сложной, то вам следует рассмотреть возможность использования DDD для борьбы с этой сложностью.
Если вы знаете, что ваше приложение будет расти и, вероятно, часто изменяться, то DDD определенно поможет вам в контроле сложности и реализации рефакторинга вашей модели с течением времени.
Если вам не понятен домен (Domain), над которым вы работаете, потому что он новый и никто ранее не вкладывал средства в это решение, это может означать, что он достаточно сложен для того чтобы с ходу начать применять DDD. В этом случае вам стоит в первую очередь начать тесное взаимодействии с экспертами предметной области (Domain Experts) для построения правильной модели.
Некоторые нюансы
Применять DDD не просто. Необходимо время и усилия, чтобы построить бизнес-домен, создать терминологию, провести исследования и организовать сотрудничество с экспертами предметной области используя единый язык, без профессиональных терминов программистов.
Вам потребуется участие экспертов предметной области. Это в свою очередь потребует открытого, здорового и непрерывного диалога, чтобы успешно перенести их терминологию в модель программного обеспечения.
Вдобавок ко всему, вам придется приложить усилия, чтобы избежать технических моментов реализации на начальном этапе, а сосредоточиться в первую очередь о поведении объектов и создании единого языка (Ubiquitous Language).
Стратегический обзор
Подтверждено, что распределенные архитектуры увеличивают общую производительность компании, поскольку они определяют границы вашего продукта, которые будут разрабатывать целевые команды разработчиков.
Если вы хотите узнать больше о стратегической части DDD, вам следует взглянуть на первые три главы книги Вона Вернона «Реализация методов предметно-ориентированного проектирования» или книгу Эрика Эвинса «Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем»
Выводы
Реализация DDD требует усилий. Если бы это было легко, все писали бы качественный код. Будьте готовы, потому что вы скоро узнаете, как писать код, который при прочтении отлично описывает бизнес вашей компании.
Domain-Driven Design: стратегическое проектирование. Часть 1
Здравствуйте, хабрапользователи! В этой статье речь пойдет о предметно-ориентированном проектировании программного обеспечения с использованием, в первую очередь, стратегических шаблонов. Вторую часть – про тактическое проектирование – читайте здесь.
Данный подход использовал Вон Вернон в своей книге «Реализация методов предметно-ориентированного проектирования». Цель написания этой книги: дать возможность разработчикам совершить полет на самолете DDD (в детстве автор зачастую путешествовал со своей семьей на небольших самолетах). Вид с высоты дает более широкое представление о проблемах моделирования, не давая застрять в различных технических деталях. Наблюдая ландшафт DDD таким способом, можно осознать преимущества как стратегического, так и технического проектирования. Подробнее – под катом!
Основной целью применения DDD является получение высококачественной модели программного обеспечения, которая будет максимально точно отражать поставленные бизнес-цели. Для реализации этого требуется объединение усилий как разработчиков, так и экспертов в предметной области. Создание дружной и сплоченной команды позволяет получить большое количество преимуществ для бизнеса. Обмен знаниями между членами команды снижает шансы появления «тайного знания» о модели, достигается консенсус между экспертами предметной области в отношении различных понятий и терминологии, разрабатывается более точное определение и описание самого бизнеса.
Для того чтобы уравнять разработчиков и экспертов предметной области, чтобы было гораздо проще обмениваться полезными знаниями о предметной области, подход DDD предлагает применять общий набор терминов, понятий и фраз, который будет использоваться в общении между членами команды, и который позже отразится в исходном коде результирующей программы.
Единый язык
Наиболее важное для разработчика – это умение слушать экспертов, получать максимальное количество полезных знаний о предметной области. В то же время, эксперты также должны прислушиваться к разработчикам и их пожеланиям. Команда учится и растет вместе, если она действует сплоченно, получая более глубокое понимание бизнеса.
Приведу несколько примеров из книги:
В команде, обсуждая модель применения вакцины от гриппа в виде кода, произносят фразу наподобие: «Медсестры назначают вакцины от гриппа в стандартных дозах». Возможные варианты развития событий:
Очевидно, что первый вариант совсем не оптимален, второй – лучше, но не учитывает некоторые важные концепции. Окончательный вариант наиболее приемлем для поставленной задачи.
Очень важно понимать, что в рамках предметной области смысл определенного термина или фразы может сильно отличаться. Существует некая граница, в пределах которой понятия
единого языка имеют вполне конкретное контекстное значение.
Ограниченный контекст
Эта концептуальная граница называется ограниченный контекст (Bounded context). Это второе по значимости свойство DDD после единого языка. Оба эти понятия взаимосвязаны и не могут существовать друг без друга.
Итак, ограниченный контекст – это явная граница, внутри которой существует модель предметной области, которая отображает единый язык в модель программного обеспечения.
Контекст банковских услуг
Сводка поддерживает запись о дебиторских и кредиторских транзакциях, отображающих текущее финансовое состояние клиента с точки зрения банка → Сводка о текущих счетах или сводка о сберегательных счетах
Сводка – это совокупность литературных выражений об одном или нескольких событиях, произошедших за определенный период времени → На сайте amazon.com продается книга Into Thin Air: A Personal Account of the Mt. Everest Disaster
Предметная область, предметная подобласть, смысловое ядро
Это и есть основа для стратегического проектирования при подходе DDD.
Пространство задач и пространство решений
Предметные области состоят из пространства задач и пространства решений. Пространство задач позволяет думать о стратегической бизнес проблеме, которая должна быть решена, а пространство решений, сосредоточится на том, как реализуется программное обеспечение, чтобы решить бизнес проблему.
Итак, для оценки пространства задач в первую очередь необходимо:
Карта контекстов
Естественный ход событий – совпадение границ контекстов с организационным делением команды. Люди, работающие вместе, разделяют один общий контекст модели.
Существуют такие отношения между ограниченными контекстами и отдельными командами проекта:
Сначала рисуется простая карта контекстов с границами и связью между ограниченными контекстами :
Например, PayeeAccount – это тот же BankingAccount, но с другим поведением (нельзя получить баланс). Таким образом будет создан отдельный контекст учета расходов (expense tracking). Также отдельно, в приведенном примере, создается контекст онлайн сервисов банка (on-line banking services) (такие сервисы, например, как распечатка выписок банка).
Детализированная карта выглядит вот так:
Так как контекст профайлов веб-пользователей используется как готовый внешний модуль и он поставляется «как есть», здесь устанавливается отношение конформист (нижестоящий подчиняется вышестоящему).
Вывод
Спасибо за внимание!
Статью подготовили: greebn9k (Сергей Грибняк), wa1one (Владимир Ковальчук), silmarilion (Андрей Хахарев).
Снова о разработке на основе предметной области (Domain-Driven Design, DDD)
Введение
Слишком много раз я встречал приложения, о которых говорили, что у них есть модель предметной области и приложение было спроектировано на основе это предметной области. Однако в действительности всё, что я видел, было коллекцией сущностей (я бы даже сказал DTO), имеющих кучу свойств без какой бы то ни было реальной логики, связанной с сущностью. Кроме того, я могу найти много сервисов всех видов, которые содержат красочную смесь бизнес-логики и/или инфраструктуры. Если приложение вдобавок использует шину сообщений (как NServiceBus, Mass Transit Bus или Azure Bus), то конечно же заметно, что некие сообщения передаются от одного модуля к другому или нескольким модулям. К сожалению, сообщения часто имеют очень обобщённые названия, содержащие слова “обновить”, “изменить”, “добавить” или “удалить”, и несут большое количество полезной нагрузки — десятки разнообразных свойств. Часто из названия сообщения совершенно не очевидно, является ли оно командой или событием, и чтобы определить это, приходится глубоко зарыться в реализацию.
Я искренне хотел бы, чтобы все написанное выше было бы преувеличением или же имело смысл только для «старых» приложений, которые разрослись и вышли из-под контроля. Но печальная истина в том, что это относится ко многим новым проектам, даже тем, которым всего несколько месяцев от роду. Почему так происходит? Конечно, есть много разных причин: отсутствие знаний является одной из наиболее важных.
DDD — Что важно?
Когда мы хотим создать новое приложение, в идеале с нуля, и мы хотим применить DDD, то нам надо учитывать вот что: не все, что было написано в синей книге, в равной степени важно. К сожалению, первые 14 глав или около того описывают детали реализации, имеющие больше общего с хорошим объектно-ориентированного программированием и не столько с проектированием на основе предметной области. Последние несколько глав книги содержат очень интересные вещи, но многие разработчики не дочитывают так далеко, и уже начали работу над реализацией своих приложений.
В поисках единого языка
Когда мы начинаем новый проект, то мы должны сначала попробовать по-настоящему понять предметную область бизнеса, для которого мы строим приложение. Нам нужно поговорить с заинтересованными лицами и экспертами в области (да, зачастую это представители клиента, для которого мы создаём программное обеспечение) и попытаться понять их язык. Нам надо внимательно слушать, что они говорят и как они говорят. Пользуются ли они определенными словами, которые понятны и используются таким же образом всеми, работающими в этой предметной области? Является ли смысл этих слов однозначным? Если нет, то мы должны задавать вопросы и требовать от экспертов более подробного описания их терминологии, либо смены формулировок, или даже использовать некие аналогии. Одна из моих любимых «игр» — это спросить экспертов о том, как бы они делали свои задачи в отсутствие компьютера. Что будет действиями, а что объектами, предметами, концепциями или существительными?
Со временем (да, это может занять несколько дней или недель, чтобы сделать это правильно), мы будем иметь общий словарь, понятный всем: заинтересованным сторонам, экспертам в предметной области, бизнес-аналитикам, архитекторам, разработчикам и тестировщикам. Мы будем называть этот словарь или «язык» «единым языком».
Обратите внимание, что единый язык, вероятно будет развиваться в течение всей жизни проекта по мере того, как мы получаем всё более и более глубокое понимание предметной области, изучая все её тонкости и узкие места.
Разделяя сложную проблему
После того, как мы нашли или определили единый язык предметной области, мы можем начать моделировать домен. Но намного чаще предметная область бизнеса, для которого мы собираемся написать программное обеспечение, является достаточно сложной, чтобы понять все сразу и/или легко упустить что-то из виду. Таким образом, мы должны начать разделять всю сложную область в меньшие части меньшей сложности. Это тот же подход, что и во время еды — мы не в состоянии проглотить весь стейк сразу, но можем разрезать его на куски, а затем съесть один кусок за другим.
Мы можем сделать так с каждой предметной областью. С помощью экспертов необходимо определить под-домены или области, которые мы можем изолировать друг от друга и посмотреть на них в отдельности, чтобы решить их в по-отдельности. Мы называем эти под-домены ограниченными контекстами (прим. пер. — bound contexts). Ограниченный контекст — это часть всей предметной области, имеющая четкие границы, взаимодействующая через четко определенные интерфейсы с другими ограниченными контекстами и которая может быть определена индивидуально.
Определение интерфейсов и контрактов
Теперь, когда мы разделили сложный бизнес домен на более мелкие и менее сложные ограниченные контексты, нам надо подумать о том, как эти контексты должны взаимодействовать друг с другом. Каждый ограниченный контекст снаружи должен выглядеть как черный ящик. Детали реализации не должны иметь значения, если я не являюсь частью этого контекста. Взаимодействие с ограниченным контекстом происходит с помощью хорошо определенных интерфейсов, используя тщательно разработанные контракты. Еще раз — это чудесно сочетается с нашим опытом в реальном мире. Если я хочу иметь дело со страховой компанией, тогда обе стороны, я и страховая компания, должны договориться о некоторых контрактах. Контракты подробно описывают наше взаимодействие, в них нет неясности.
После того как контракт создан и подписан обеими сторонами, его уже тяжело изменить: это возможно сделать, но придется приложить усилия. Точно так же мы должны думать при определении интерфейсов и контрактов для наших ограниченных контекстов. Контракты — это сообщения (команды и события), которыми обмениваются контексты. Именно здесь имя и содержимое контракта имеют значение. Имя определяет контекст команды или события, а содержимое — разницу в данных, необходимую для перехода из одного состояния в другое.
Мы должны чётко различать команды и события. Команда всегда имеет только одну цель. Цель команды может либо принять, либо отклонить команду. Результатом выполнения команды, как правило, является изменение в системе. Было сделано что-то, что изменило состояние модели. С другой стороны, событие может иметь от нуля до нескольких подписчиков. Да, это верно, что события могут быть проигнорированы… но события никогда не могут быть отклонены, поскольку они сообщают нам о том, что уже произошло. Чтобы чётко отличать команды от событий, мы должны использовать императивные имена для команд; события же должны называться в прошедшем времени. Имена должны использовать созданный нами единый язык.
Чего мы должны избегать в DDD
Если мы хотим использовать проектирование на основе предметной области при разработке, мы должны избегать нескольких ловушек.
Строить приложение только вокруг данных
В прошлом большинство бизнес-приложений были ориентированы на данные. В первую очередь архитекторы и инженеры создавали схему данных, а всё остальное следовало за ней. Люди говорили»… в конце дня, только данные имеют смысл… Данные, которые мы собираем — наша ценность. Приложения, которые собирают и/или используют данные появляются и исчезают, но сами данные остаются… «. И хотя данные остаются, просто неправильно утверждать, что данные — это всё, что имеет значение! Данные сами по себе не имеют смысла. Отдельно данные лежат мёртвым грузом и только логика придаёт им смысл. И одни и те же данные имеют различное значение в разных контекстах. Таким образом, мы всегда должны начинать с контекста и логики.
Когда я разрабатываю приложение, ERD (ER-модель данных — прим.пер.) является одной из наименее важных вещей для меня. Я не позволяю себе и модели моей предметной области быть подконтрольными хранилищу данных или модели данных. Для меня бизнес-приложение не означает автоматически, что я должен использовать СУБД, и что моя модель данных должна быть в 3-й нормальной форме!
Говорить о деталях реализации
Использовать технический шум
Очень общие термины, как «менеджер» необходимо также избегать. Что делает менеджер? Что значит «управляет»? Нет, нет, пожалуйста, дайте нам больше контекста!
Транзакции БД
Хотя транзакции БД — это хорошая вещь, не стоит злоупотреблять ими. Бизнес-транзакции являются гораздо более важными, нежели транзакции БД. Несмотря на то, что по определению, транзакции БД полностью целостны (и выполняются быстро), бизнес-транзакции таковыми не являются. Пример бизнес-транзакции, с которой вы все вероятно хорошо знакомы — то, что происходит в Starbucks, когда утром вы заказываете любимый кофе. Это «долгий» процесс со многими возможно «противоречивыми» промежуточными состояниями и асинхронными задачами. Тем не менее, всё это работает, масштабируется и широко принято всеми.
Таким образом, при моделировании вашей предметной области с помощью DDD, не думайте о транзакциях БД (или еще хуже «распределенных транзакциях») вообще. Думайте о возможных действиях, их результатах и о сценарии отмены действия в случае неудачи. И вы увидите, что вы будете решать главным образом бизнес-проблемы, а не бороться с техническими проблемами.
Что можно узнать о Domain Driven Design за 10 минут?
Говорят, что можно бесконечно смотреть на огонь, наблюдать за тем, как работают другие, а также изучать 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 в компании сверху вниз
7. Как научить человека DDD без его ведома
Конечно же, через практику. Просто не говорите человеку заранее, что учите его DDD, не пугайте раньше времени.
Пусть человек приходит и получает задачки. Не говорите ему, что это DDD, пусть просто делает. Он сделает, исходя из того, как он понимает солиды и всё такое. Потом, когда он будет сдавать работу, ему нужно сказать: «Дорогой чувак, оно вроде работает, но его нужно переделать», — и объясняете ему почему.
Не заставляйте читать или учить всё целенаправленно. Будьте интерактивными в этом плане. Так человек за 3-5 месяцев начнёт понимать базовые принципы DDD: с точки зрения реализации, с точки зрения теории. Паттерны он начнёт понимать ещё раньше по артефактам подхода – картам контекстов. Сначала людям будет ничего непонятно, но постепенно они врубятся, а некоторые даже книжки начнут читать.
8. Умею DDD — неважная строчка для резюме в России
Если вы находитесь в России и знаете DDD — это круто. Но далеко не факт, что сами знания DDD пригодятся в работе. Скорее, это будет служить индикатором для работодателя о вашем высоком уровне развития как разработчика. Ведь навыки, которые вы приобретаете, изучая подход DDD, развивают вас как программиста и как проектировщика (архитектора).
А вот если вы задумываетесь о переезде за границу, то такая строчка в резюме может оказать положительное влияние. За границей DDD-комьюнити намного больше, и сам подход намного популярнее, чем у нас. Особенно в Европе.
9. Связь DDD с волосами на лице
Наблюдение: люди, которые разбираются в DDD, носят бороды. Значит ли это, что наличие бороды — предпосылка к успешности в DDD? Вы как считаете?
10. Полезные материалы по DDD
Подкаст «Ничего такого». Дорогой читатель, эта статья была написана под впечатлением от выпуска нашего подкаста. Нам стало интересно как выглядит культура, строятся команды и процессы в разных технологических компаниях вроде Miro, Яндекса, Amazon, Microsoft, Едадила. Поэтому мы встретились с ребятами оттуда и поболтали на эти темы.