Некоторые люди говорят, что DDD сложно, затратно и должно использоваться с осторожностью. Некоторые команды практикуют «DDD Life» — они используют паттерны проектирования приложений, описанные Эриком Эвансом в большой синей книге, но игнорируют идеи, которые считаются на самом деле важными.
По правде говоря, я никогда не работал над проектом с использованием «настоящего DDD» (пока что!). Тем не менее, DDD вдохновило меня и я верю, что оно сделало меня более профессиональным разработчиком. Я использую маленькие кусочки и части DDD, большинство из которых нельзя назвать «настоящим DDD», но я точно помню, откуда приходит вдохновение.
Я считаю, что истинная ценность труда Эванса в том, что практически каждый может использовать некоторые идеи, которые он предложил. Они не требуют каких либо специальных инструментов, денег, согласования или реорганизации. Это те простые идеи, которые вы можете начать воплощать в жизнь уже с понедельника (или завтра). Я называю эти идеи «DDD Ultra-Lite». Некоторые из них не новы, но я верю, что Эванс проделал хорошую работу для описания DDD понятными словами и метафорами во избежание моментов непонимания.
Итак, вот эти идеи (в случайном порядке):
1. Прислушивайтесь к тому, что говорит бизнес
Я не шучу. Этот совет, вероятно, такой же старый, как и программирование само по себе, но Эванс описывает эту идею достаточно интересно.
Он говорит, что если бизнес не понимает вашей модели или думает, что она неверна, это означает, что вам нужно над ней ещё поработать. Иногда люди из бизнеса открыто не критикуют вашу идею, но она их тревожит и вводит в заблуждение, кажется неправильной.
Иногда бывает и наоборот. Вы наконец находите хорошую модель и при общении с бизнесом на вас смотрят, как на тупейшего человека в мире. «Да, вы правы, это очевидно, но почему у вас заняло так много времени понимание этих концепций?». Это означает, что вы наконец на верном пути.
2. Проектируйте ровно столько, сколько нужно, не больше и не меньше
Избыток и недостаток проектирования — это проблемы. Найти баланс между глубоким проектированием и только «исполнением функций для достижения цели» — это нетривиальная задача. Эванс даёт нам несколько советов, которые я нахожу очень полезными:
- Используйте простейшую модель, которая решает текущую проблему. Не пытайтесь спроектировать реальность, вы не сможете.
- Помните о чистоте кода. Ваш код и архитектура должна легко изменяться в будущем. Если ваш проект успешен, тогда вы будете менять архитектуру множество раз. Вы не сможете спроектировать идеал с первого раза (и, наверное, никто не сможет).
- Если код начинает «уходить» от вас и вы видите, что вносить изменения становится всё сложнее, это знак о том, что проблема в текущей модели. Время рефакторинга этой части программы.
- Рефакторьте маленькие части системы по мере необходимости, снова проектируя простейшую модель, которая решает новую проблему.
- Обсуждайте. За чашкой кофе с разработчиками и архитекторами. Обсуждайте вашу проблему с ними, проводите мозговой штурм, выспитесь и возвращайтесь ещё.
- Не обсуждайте больше, чем нужно. Эванс предполагает множественные итерации, короткие дискуссии(1-1.5 часа), обучение и общение.
3. Задавайте сложные вопросы
Иногда я работаю над новой функциональностью и модифицирую существующую и архитектура начинает становиться уродливой. Она была неплохой до этих изменений, но вдруг стала слишком сложной или просто плохо начала смотреться. Это знак того, что архитектуру пора менять, ничего особенного. Тем не менее, книга Эванса дала мне несколько вопросов, которые необходимо задать в таких случаях: Я упустил что-либо в концепции домена? Это изменение добавляет или использует концепцию, которая не подходит к текущей модели?
Другими словами, вместо добавления ещё нескольких if-ов или дополнительных классов, возможно, стоит пересмотреть архитектуру и найти что-либо более подходящее или принципиально другое.
4. Не изобретайте колесо.
Эванс рекомендует искать внешнее вдохновение несколько раз в книге. Можно просматривать каталоги паттернов, чтобы найти что-либо, что можно использовать оттуда (возможно, с модификациями). Он рекомендует ознакомиться с тем, как похожие проблемы решаются в других контекстах (областях).
Что самое интересное, мне приходилось множество раз упускать этот подход. Многие люди ищут решения в интернете — в различных блогах, смотрят презентации. И почти никогда я не слышу, чтобы кто-либо сказал:«Я читал об этом в книге XYZ». Обычно сессии «проектирования», которые я посещал, являлись обычным мозговым штурмом. И потом, спустя месяцы, я мог наткнуться на случайную презентацию, которая показывала другой подход к решению нашей проблемы, значительно более предпочтительный.
Многие люди на конференциях пытаются найти решения в других областях знаний. Они пытаются найти решения общих проблем и адаптировать их под свои специфические нужды. Но, тем не менее, в «реальной жизни» очень часто наш кругозор не слишком велик и мы не можем позволить себе большое исследование.
Улучшение, которое я сделал лично для себя в области «исследования проблемы» — использовать более организованные источники и просматривать классические источники. Блоги и презентации очень ценны, но, не поймите меня не правильно, книги лучше организованы и содержат более проверенную временем информацию. Тем не менее, никто не оспаривает «великолепные» статьи в обычном случайном поиске гугла. Если они написаны экспертами, то это должно подходить в большинстве случаев. Но даже эксперты не всегда объясняют свои решения и подробно описывают проблему.
Если я вспоминаю что-либо, что может быть полезным, я возвращаюсь к источнику этой информации для освежения памяти. Я пытаюсь найти связанные статьи, книги или презентации. Если я понятия не имею, с чего начинать, есть несколько идей, которые для меня полезны: возвращение к теории, просмотр каталогов (по паттернам или проектированию), фокусирование на контексте и описании проблемы, поиск хороших практик от IT профессионалов в конкретной области.
Заключение
Всё это достаточно тривиально, но я советую вам попробовать применять всё это так, «как вы это понимаете». Вы будете удивлены.