Чему я научился у классика Эрика Эванса
Прошло некоторое время с тех пор, как я добавил книгу Эрика Эванса в свой список для чтения. Я много слышал об этом от сообщества разработчиков: «Это изменит то, как вы делаете свою работу», — говорили они. Я выбрал его книгу несколько месяцев назад, без каких-либо ожиданий. В этой статье я хотел бы поделиться своими мыслями и уроками, извлеченными из этой книги.
Итак, что же такое «Дизайн, управляемый предметной областью» (DDD) Эрика Эванса и почему это слово стало модным в последние несколько лет?
Это набор принципов для разработки надежного, расширяемого и понятного программного обеспечения. Потребность в программном обеспечении — это домен, в котором есть свои эксперты в этой области. Допустим, клиент хочет бухгалтерское программное обеспечение для компании среднего размера. Можно сказать, что областью является бухгалтерский учет, а эксперты в этой области могут быть бухгалтерами.
С другой стороны, есть разработчики, которым нужно удовлетворять потребности экспертов в предметной области. Разработчики и бухгалтеры говорят на разных языках. Чтобы они понимали друг друга, должны соблюдаться некоторые правила общения. Отбрасывая его от технических терминов, мы приходим к повсеместному языку. Этот словарь должен содержать только термины из домена. Это дает специалистам в предметной области понимание того, как работает их программное обеспечение. Разработчики могут использовать его для понимания потребностей специалистов в предметной области в контексте программного обеспечения.
Другой важной частью DDD является то, как поддерживать структуру и расширяемость программного обеспечения. Эрик рассказывает о нескольких шаблонах проектирования и о том, как они могут работать вместе в контексте предметной области. Я не буду углубляться в это, но имейте в виду, что это части всего подхода.
Вы действительно используете DDD?
Распространенным заблуждением, которое я часто встречал, является неправильное использование этого термина. Я получаю тонны личных сообщений на LinkedIn от рекрутеров и менеджеров по персоналу, говорящих, что они используют DDD. Но так ли это? Наличие кода, структурированного в поддоменах, не означает, что он разработан на основе домена. Единственный способ, которым DDD может работать, — это только в том случае, если все находятся за границей с этой идеей. Без понимания предметной области обеими сторонами невозможно сотрудничество.
Я вижу, как разные команды перенимают некоторые идеи из книги, но не единую концепцию. Это становится ясно после дальнейших разговоров с разными людьми, и результат всегда один и тот же. Разработчики часто используют шаблоны проектирования и структурируют код. Когда я спрашиваю потенциальных экспертов в предметной области, понимают ли они модель, они почти ничего не понимают.
Посадить всех на DDD сложно, а тем более удержать всех на нем. Во многих случаях наличие такой структуры может только запутать, а не упростить. Я бы не рекомендовал эту терминологию для небольших или краткосрочных проектов. Требуется время, чтобы принести плоды того, что предлагает дизайн, ориентированный на предметную область.
Хорошие вещи
Как разработчик, я нашел практические примеры и шаблоны наиболее полезными. Единственная их цель — содержать ваш код в чистоте и порядке. В каком-то смысле это напомнило мне «Рефакторинг» Мартина Фаулера (Эванс тоже использует положительные моменты и ссылки в своей книге). Я оценил связь между сильными шаблонами проектирования и кодовой базой DDD.
Эванс также пишет о различных методах структурирования доменов и поддоменов. Есть несколько хороших моментов о том, как начинать новые проекты с таким подходом, а также о том, как работать с унаследованным кодом. Некоторые техники более абстрактны и странны для меня, чем другие. Мне также понравились главы о формировании вездесущего языка и о том, как привлечь к нему людей.
Дизайн, ориентированный на предметную область, не всегда возможен
Поскольку я понимаю, что представляет собой этот процесс, я также могу представить себе случаи, когда он может навредить. Как я уже писал ранее, я не вижу смысла использовать DDD на небольших проектах. Понятия, упомянутые в книге, добавляют не только ясности, но и много абстракции. В меньшем проекте, например, личной веб-странице, я не рассчитываю управлять более чем дюжиной сущностей. Для такой кодовой базы наличие высокой абстракции может быть бременем.
Где я также с трудом могу себе представить, как это сделать, так это в приложениях, ориентированных на производительность. Высокий уровень абстракции может замедлить работу приложения. Последний тип проектов DDD контрпродуктивен — это краткосрочные проекты. Когда у нас что-то работает в течение короткого промежутка времени, скажем, меньше года, опять же, нам не нужно, чтобы код был идеальным. Желательно минимизировать расходы, тратя меньше времени на такие проекты.
Краткое содержание
Подводя итог, можно сказать, что книга Эванса «Дизайн, управляемый предметной областью» — отличная книга. Это дает много информации о различных подходах и методах разработки. В целом этот процесс может работать только с определенными типами проектов, хотя он содержит некоторые замечательные идеи об абстракции кода.
Я рекомендую ее, так как это отличное чтение для каждого разработчика программного обеспечения, серьезно относящегося к своей карьере. Я бы также порекомендовал другие книги о шаблонах проектирования, например «Рефакторинг» Мартина Фаулера. Это может предложить еще более глубокое понимание того, как структурировать ваш код.
Спасибо, что прочитали мою статью! Если вам понравилось, не стесняйтесь поделиться или подписаться.
