Тебе не нужен DDD

Бывает для изменения вывода формы обратной связи нужно изменить десяток классов. Зачем же так делать? Ведь вроде все мы стремимся снизить сложность проектов, а получается ровно обратная ситуация. Иногда к такому положению приводит такой благой мотив как использование Предметно-ориентированного проектрирования aka Domain Driven Design. Сегодня о том, когда не нужно использовать этот инструмент и какие нужны условия если очень хочется.

TLDR

Не нужно использовать если:

• Разработчик является доменным экспертом;
• Разработка не общается с доменными экспертами;
• Разработка не знает как внедрять;

А если очень хочется, то:

• Вся разработка в одной комнате
• Пишите тесты
• Пишите меньше

Домен наше всё

Доменные эксперты хранят истину, прямо как база данных для приложения. А если хранилища нет, то информация остается в приложении и когда приложение падает…понятно что происходит. Так же и с людьми. Когда разработчик определяет как структурируется приложение, мы сознательно отказываемся от базы данных. Разработка развивается, люди меняются и в итоге мы получаем приложение с десятком различных подходов. Отсюда первой причиной отказаться от DDD я считаю отсутствие доменных экспертов.

Базы данных тоже иногда сбоят и тогда мы делаем отказоустойчивые конфигурации. Так же проявляется и второе преимущество Предметно-ориентированного проектирования - Вездесущий язык. Он выступает своего рода отказоустойчивой системой для хранилища. Когда меняется команда разработки, сохранившийся язык подсказывает структуру приложения. Когда доменный эксперт упускает противоречащие нюансы процесса, приложение явно сигнализирует о них. Бывает что между авторами кода приложения и бизнес процессов существует непреодолимая коммуникационная “стена”. В таком положении я бы стал строить модель от предметной области только при уверенности что “стена” отлично понимает доменных экспертов и мы можем гибко менять приложение.

Эванс был не прав

Для многих знакомство с DDD начинается с книги Эрика Эванса “Domain-Driven Design: Tackling Complexity in the Heart of Software”. Книга разделена на 4 части, которые упорядочены таким образом, что в процессе изучения фокус важности смещается на то, как реализовывать подход. В то же время, причины и цели такого метода проектирования раскрываются лишь под конец книги. В 2009-м году на конференции QCon London 2009 автор говорит “Ubiquitous Language and Context Mapping and Core Domain are at the center” пытаясь донести, что первичны стратегические аспекты Предметно-ориентированного проектирования и они раскрыты слишком поздно в книге.

Человеку свойственно стремиться “быть хорошим”, что в данном контексте выражается в желании делать как подсказывают более опытные коллеги. Вот мы и создаем приложения с фокусом на реализации. Код таких произведений получаются “многословными” и часто избыточно сложным, абстрактным. Чтобы не попасть в такую ловушку важно помнить о главном - Зачем мы проектируем таким образом? Какую именно выгоду мы хотим получить от использования DDD? А для этого совершенно не обязательно “реализовывать десяток классов”.

А как учиться

Думаю, никто не родился с врождённым навыком проектирования по предметной области, значит как то мы учимся. Я бы выделил несколько необходимых условий проекта в котором можно практиковаться в Domain Driven Design:

• Вся разработка в одной комнате. Близкое общение позволит сохранить единый язык хотя бы у разработки.
• Пишем тесты. Они помогут переписать модель когда промахнемся. А промахиваться будем часто.
• Нам не платят за строчки кода. Стремитесь писать меньше, это поможет увидеть конфликты в модели при помощи тестов.

Резюме

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