В предыдущих главах мы рассмотрели три основных строительных блока наших областей: DTO, действия и модели. Сегодня мы сделаем передышку от низкоуровневых технических вещей и сосредоточимся на философской стороне: как начать использовать домены, как их идентифицировать и как управлять ими в долгосрочной перспективе.
Все статьи серии
Командная работа
В начале этой серии статей я утверждал, что все парадигмы и принципы, о которых я пишу, будут служить определенной цели: помогать командам разработчиков поддерживать их большие приложения Laravel в течение многих лет.
Некоторые люди высказывали свое беспокойство: не затруднит ли новая структура каталогов и использование сложных принципов подключение новых разработчиков?
Если вы разработчик, знакомый с проектами на Laravel и с тем, как они подаются новичкам, то вам действительно нужно потратить некоторое время на изучение того, как эти проекты устроены. На самом деле это не так уж и важно.
Представьте себе проект с примерно 100 моделями, 300 действиями, почти 500 маршрутами. Это тот масштаб проектов, в которых я работаю. Основная трудность в этих проектах заключается не в том, как код технически структурирован, а в огромном объеме бизнес-знаний, которые необходимо усвоить. Вы не можете ожидать, что новые разработчики поймут все проблемы, которые решает этот проект, просто в одно мгновение. Требуется время, чтобы узнать код, но еще важнее-бизнес. Чем меньше магии и косвенности, тем меньше места для путаницы.
Важно понять цель архитектуры, которую я объясняю в этой серии статей: это не о том, чтобы написать самое короткое количество символов, это не об элегантности кода; это о том, чтобы сделать большие кодовые базы проще для навигации, чтобы было как можно меньше места для путаницы и сохранить проект здоровым в течение длительных периодов времени.
У нас действительно есть опыт работы с этим процессом на практике: поработав с командой из трех разработчиков над одним из наших проектов, мой коллега Рубен присоединился в качестве нового бэкенд-разработчика.
Архитектура была для него в новинку, хотя он уже имел опыт общения с Laravel. Мы нашли время, чтобы обучить его. После нескольких часов инструктажа и парного программирования он уже мог работать в этом проекте самостоятельно. Конечно, потребовалось несколько недель, чтобы получить полное представление о масштабах проекта, но, к счастью, архитектура не стояла у него на пути — наоборот: это помогло Рубену сосредоточиться на бизнес-логике.
Данная архитектура не является серебряной пулей для каждого проекта. Есть много случаев, когда более простой подход может работать лучше. Но может случиться и так, что для некоторых случаев потребуется более сложный подход.
Идентификация доменов
С учетом того, что мы теперь знаем об основных строительных блоках предметной области, возникает вопрос о том, как именно мы начинаем писать реальный код. Существует множество методик, которые вы можете использовать, чтобы лучше понять, что вы собираетесь построить, хотя я чувствую, что есть два ключевых момента:
- Даже если вы разработчик, ваша основная цель-понять бизнес-проблему и перевести ее в код. Сам по себе код-это всего лишь средство достижения цели; всегда концентрируйтесь на проблеме, которую вы решаете.
- Убедитесь, что у вас есть личное время с вашим клиентом. Потребуется время, чтобы извлечь знания, необходимые для написания рабочей программы.
Я стал думать о своем описании работы все больше и больше как “переводчик между реальными мировыми проблемами и техническими решениями”, а не “программист, который пишет код”. Я твердо верю, что этот образ мышления является ключевым, если вы собираетесь работать над долгосрочным проектом. Вы не просто должны написать код – вам нужно понять реальные проблемы, которые вы пытаетесь решить.
В зависимости от размера вашей команды вам может не понадобиться личное взаимодействие между всеми разработчиками и клиентом, но тем не менее все разработчики должны понимать проблемы, которые они решают с помощью кода.
Эти командные динамики – настолько сложная тема, что они заслуживают отдельной книги. На самом деле существует много литературы именно на эту тему. Пока я не буду останавливаться на этом, потому что с этого момента мы можем говорить о том, как мы переводим эти проблемы в Домены.
В главе 1 я писал, что одна из целей этой архитектуры состоит в том, чтобы сгруппировать код, который принадлежит друг другу, основываясь на их значении в реальном мире, а не на их технических свойствах. Если у вас есть открытая коммуникация с вашим клиентом, вы заметите, что требуется время — много времени — чтобы получить хорошее представление о том, что представляет собой его бизнес. Часто ваш клиент может и сам не знать этого в точности, и только сев, он начинает основательно думать об этом.
Вот почему вы не должны бояться доменных групп, которые меняются с течением времени. Вы можете начать с Invoice домена, но через полгода заметите, что он стал слишком большим для вас и вашей команды, чтобы полностью охватить его. Возможно, генерация счетов и платежи – это две сложные системы сами по себе, и поэтому они могут быть разделены на две доменные группы в дальнейшем.
Моя точка зрения заключается в том, что полезно продолжать итерацию над вашей доменной структурой, продолжать ее рефакторинг. При наличии правильных инструментов это нетрудно сделать. Мой коллега Фрик нашел время записать практический пример, в котором он делает рефакторинг приложения Laravel с дефолтной структурой в структуру, описанной в этой серии статей. Вы можете взглянуть на его живую сессию рефакторинга ниже.
Таким образом, не бойтесь начинать использовать домены, потому что вы всегда можете рефакторировать их позже.
Если вы захотели начать использовать эту предметно-ориентированную архитектуру, то попробуйте определить подсистемы в рамках вашего проекта, понимая, что они могут и будут меняться с течением времени. Вы можете сесть с вашим клиентом, вы можете попросить его записать некоторые вещи или вы можете даже сделать сеансы мозгового штурма с ним. Вместе вы формируете образ того, каким должен быть проект и этот образ вполне может быть уточнен и даже изменен в будущем.
И поскольку наш доменный код имеет очень мало зависимостей, он очень гибок, не требует больших затрат на перемещение или рефакторинг вашего кода.
