В одном романе для того, чтобы подчеркнуть бесспорную красоту и поразительную сексуальность одной из героинь, автор использовал фразу: "She was a such kind of woman, that every man look at twice". Что в литературном переводе можно понять: "Она была такой женщиной, что каждый мужчина оборачивался ей в след".

И точно такую же фразу я могу применить к бесподобной книге "Предметно-ориентированное проектирование (DDD)" Эванса Эрика. К ней хочется возвращаться каждый раз, когда ты садишься за проектирование системы в незнакомой тебе области. Словно маяк во время шторма, она помогает вести вашу галеру через сложности, чтобы все гребцы увидели землю, а проект увидел успешный старт.

И в этом обзоре, я расскажу, почему, по моему мнению, это MUST HAVE книга для каждого middle+ разработчика.

Как обычно выглядят книги по проектированию 

Большинство книг по проектированию систем скатываются к тому, чтобы обсуждать какие-то конкретные шаблоны проектирования в абстрактной ситуации. Нам сначала описывается какая-то система в первоначальной ситуации, потом добавляются дополнительные условия в виде изменчивости системы, а потом рассказывается паттерн, как правильно построить код, чтобы системы была поддерживаемой и расширяемой.

Если это чуть более приземленные книги, то там уже описываются какие-то реальные кейсы из опыта практикующих программистов и архитекторов, как они строили код, чтобы сделать систему поддерживаемой и расширяемой. Иногда даже добавляется юмор, чтобы сделать повествование более приятным.

И главная проблема этих книг заключается в том, что они описывают какое-то четкое начальное состояние системы. Описывают вызовы стоящие перед системой. А потом дается алгоритм перевода системы из начального состояния в нужное, героически преодолевая трудности.

И это на самом деле крутые книги! Каждый программист должен их знать и применять паттерны в своей работе.

Но, что если у вас нет начального состояния

Представьте, что вас ночью вывезли из дома в непонятном направлении, по приезду посадили в темной комнате с пачкой непонятных бумаг, рядом посадили несколько товарищей по несчастью и сказали, чтобы вы написали систему доставки топлива к нефтяным танкерам. Что-то мне подсказывает, что ни паттерны банды четырёх, ни шаблоны корпоративных приложений Фаулера вам не помогут. 

Что вам поможет? Понимание, с чего начать и куда двигаться, если кругом неизвестность. И именно про это на самом деле книга DDD Эванса.

• Как понять, c чего нужно начать проектировать систему;

• Как выделить в будущей системе ключевые понятия;

• Как найти общий язык с заказчиком проекта, наладить диалог и трансфер знаний от специалистов области к программистам;

• Как построить упрощенные модели, чтобы новые разработчики могли работать без понимания всего контекста бизнеса заказчика;

• Как ограничить контекст работы, чтобы над проектом могли работать несколько команд разработчиков, не мешая друг другу;

• Как выстраивать отношения с соседними командами, если у них либо низкая мотивация, либо слишком много воздействия на вашу команду;

И хотя может показаться, что это какие-то темы больше про менеджмент, нежели про написание кода. Это не так.

Эванс дает примеры из своей жизни, как ответы на эти вопросы кардинально меняли понимание того, как должна работать система. А значит все абстракции, которые до этого были написаны крутыми программистами - выбрасывались в мусорное ведро. Ведь программисты главным образом решают проблемы бизнеса, а не строят коней в вакууме.

Взаимоотношения не описываются схемами

Типичное желание любого программиста при проектировании системы расписать, либо модель классов и их отношения между собой, либо какой-то псевдокод того, как элементы системы зависят друг от друга.

Однако, по мнению Эванса, это не работает, так как не каждое взаимодействие в реальной жизни можно описать схематично. Поэтому нужно описывать будущую систему не с позиции того, как элементы зависят друг от друга, а что система должна делать с этими элементами и давать на выходе.

Это именно та проблема, когда разработчики героически преодолевают несуществующие проблемы, а заказчику нужно совсем другое.

Успех проекта не зависит от кода

Отдельно хочется выделить заключительную главу, где Эванс честно признается, что методология проектирования систем в ряде случаев оказывается бесполезной. Ибо либо заказчик урезает бюджет, либо уходят ключевые сотрудники, либо это просто становится никому не нужно и так далее. Что опять же возвращает читателя к мысли, что программисты должны решать проблемы бизнеса, а не строить коней в вакууме. 

Одним словом мировой мужик, честно признает ограничения методологии.

Эта книга не нужна новичкам

Чтобы прочувствовать всю боль от ситуаций, которые описываются в книге, нужно иметь адекватный коммерческий опыт, желательно опыт при работе с большими заказчиками в неизвестной вам области. Прямо зайдет! Новички же книгу просто не поймут, и вряд ли смогут хоть как-то продуктивно использовать её опыт. Как говорится всему свое время.

Вперед к знаниям!

Если вы еще не знакомы с DDD, и не читали эту книгу, то обязательно выделите в своем графике саморазвития время на эту книгу. Без всяких сомнений она пойдет на пользу и углубит ваше понимание в проектировании систем.