В одном романе для того, чтобы подчеркнуть бесспорную красоту и поразительную сексуальность одной из героинь, автор использовал фразу: "She was a such kind of woman, that every man look at twice". Что в литературном переводе можно понять: "Она была такой женщиной, что каждый мужчина оборачивался ей в след".
И точно такую же фразу я могу применить к бесподобной книге "Предметно-ориентированное проектирование (DDD)" Эванса Эрика. К ней хочется возвращаться каждый раз, когда ты садишься за проектирование системы в незнакомой тебе области. Словно маяк во время шторма, она помогает вести вашу галеру через сложности, чтобы все гребцы увидели землю, а проект увидел успешный старт.
И в этом обзоре, я расскажу, почему, по моему мнению, это MUST HAVE книга для каждого middle+ разработчика.
Как обычно выглядят книги по проектированию
Большинство книг по проектированию систем скатываются к тому, чтобы обсуждать какие-то конкретные шаблоны проектирования в абстрактной ситуации. Нам сначала описывается какая-то система в первоначальной ситуации, потом добавляются дополнительные условия в виде изменчивости системы, а потом рассказывается паттерн, как правильно построить код, чтобы системы была поддерживаемой и расширяемой.
Если это чуть более приземленные книги, то там уже описываются какие-то реальные кейсы из опыта практикующих программистов и архитекторов, как они строили код, чтобы сделать систему поддерживаемой и расширяемой. Иногда даже добавляется юмор, чтобы сделать повествование более приятным.
И главная проблема этих книг заключается в том, что они описывают какое-то четкое начальное состояние системы. Описывают вызовы стоящие перед системой. А потом дается алгоритм перевода системы из начального состояния в нужное, героически преодолевая трудности.
И это на самом деле крутые книги! Каждый программист должен их знать и применять паттерны в своей работе.
Но, что если у вас нет начального состояния
Представьте, что вас ночью вывезли из дома в непонятном направлении, по приезду посадили в темной комнате с пачкой непонятных бумаг, рядом посадили несколько товарищей по несчастью и сказали, чтобы вы написали систему доставки топлива к нефтяным танкерам. Что-то мне подсказывает, что ни паттерны банды четырёх, ни шаблоны корпоративных приложений Фаулера вам не помогут.
Что вам поможет? Понимание, с чего начать и куда двигаться, если кругом неизвестность. И именно про это на самом деле книга DDD Эванса.
Как понять, c чего нужно начать проектировать систему;
Как выделить в будущей системе ключевые понятия;
Как найти общий язык с заказчиком проекта, наладить диалог и трансфер знаний от специалистов области к программистам;
Как построить упрощенные модели, чтобы новые разработчики могли работать без понимания всего контекста бизнеса заказчика;
Как ограничить контекст работы, чтобы над проектом могли работать несколько команд разработчиков, не мешая друг другу;
Как выстраивать отношения с соседними командами, если у них либо низкая мотивация, либо слишком много воздействия на вашу команду;
И хотя может показаться, что это какие-то темы больше про менеджмент, нежели про написание кода. Это не так.
Эванс дает примеры из своей жизни, как ответы на эти вопросы кардинально меняли понимание того, как должна работать система. А значит все абстракции, которые до этого были написаны крутыми программистами - выбрасывались в мусорное ведро. Ведь программисты главным образом решают проблемы бизнеса, а не строят коней в вакууме.
Взаимоотношения не описываются схемами
Типичное желание любого программиста при проектировании системы расписать, либо модель классов и их отношения между собой, либо какой-то псевдокод того, как элементы системы зависят друг от друга.
Однако, по мнению Эванса, это не работает, так как не каждое взаимодействие в реальной жизни можно описать схематично. Поэтому нужно описывать будущую систему не с позиции того, как элементы зависят друг от друга, а что система должна делать с этими элементами и давать на выходе.
Это именно та проблема, когда разработчики героически преодолевают несуществующие проблемы, а заказчику нужно совсем другое.
Успех проекта не зависит от кода
Отдельно хочется выделить заключительную главу, где Эванс честно признается, что методология проектирования систем в ряде случаев оказывается бесполезной. Ибо либо заказчик урезает бюджет, либо уходят ключевые сотрудники, либо это просто становится никому не нужно и так далее. Что опять же возвращает читателя к мысли, что программисты должны решать проблемы бизнеса, а не строить коней в вакууме.
Одним словом мировой мужик, честно признает ограничения методологии.
Эта книга не нужна новичкам
Чтобы прочувствовать всю боль от ситуаций, которые описываются в книге, нужно иметь адекватный коммерческий опыт, желательно опыт при работе с большими заказчиками в неизвестной вам области. Прямо зайдет! Новички же книгу просто не поймут, и вряд ли смогут хоть как-то продуктивно использовать её опыт. Как говорится всему свое время.
Вперед к знаниям!
Если вы еще не знакомы с DDD, и не читали эту книгу, то обязательно выделите в своем графике саморазвития время на эту книгу. Без всяких сомнений она пойдет на пользу и углубит ваше понимание в проектировании систем.
