5 способов провалиться на внедрении DDD

1
Зайруллин Роман Равильевич3/13/2020

Спустя годы после выхода «‎Domain Driving Design», идеи Эванса вошли в мейнстрим. Разработка через моделирование должна была устранить неопределенность, позволить разрабатывать ПО за меньшее число итераций. Должна была, но ничего не вышло.

На собеседованиях и митапах я слышу

> Мы пытались внедрить DDD, но у нас не получилось

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

5 способов провалиться на внедрении DDD

## Попытки дословно следовать книге Эванса ##

У большинства книг по методикам разработки одна и та же болезнь — хорошо сформулированных идей \ эвристик \ дельных примеров — страниц 20 от силы. Остальное занимают вдохновляшки и бесполезные листинги. В качестве проверки можете взять «‎Domain Driving Design» или «‎Рефакторинг» Фаулера и заклеить стикерами все листинги. Для восприятия ничего не изменится. Аналогичное работает с большинством примеров в книге Эванса. А все стенограммы интервью можно заменить на список

  • Общайтесь с пользователями и заказчиками.
  • Уточняйте с ними модель.
  • Для реализации нужно будет не все, что говорит заказчик.

Также очень много излишне общих рекомендаций. Подобное может сработать, только если читатель интуитивно (и при этом правильно) понимает, как проводить такие интервью, какие вопросы задавать. То есть, если читатель уже умеет общаться, то стенограммы ему не нужны. Если не умеет — стенограммы бесполезны, потому что не поясняют «‎как».

Можно взять эти стенограммы как шаблон и попытаться провести интервью с заказчиками по нему. Тут же появляются проблемы:

  • Собеседник будет вести себя иначе, чем это указано в шаблоне.
  • Ответы собеседника могут быть как очень емкими, так и почти бесполезными. Строить наводящие вопросы без конкретного понимания, «‎а что же я ищу» — бесполезно.
  • «‎Ну вроде все понятно». Иллюзия понимания от неоднозначных формулировок превращает любую начерченную при разговоре схему в мусор.

Аналогично с другими комментариями \ призывами

  • Домен должен быть изолирован!
  • Архитектура должна следовать модели!

Большинство внедрений валится именно на этом. Это хорошие лозунги, но они не объясняют, как именно это делать.

Другой подводный камень в дословном следовании Эвансу -- отображение модели в код.

Эванс в своей книге следует очень вредному представлению из объектно-ориентированного проектирования, что «‎объект -—  это существительное, а метод \ функция -—  глагол». При том, что описание действий в виде объектов — распространенная практика. Даже у банды описаны шаблоны «‎Стратегия» и «‎Команда», которые как раз оперируют действием как самостоятельным понятием. Иногда эта ошибку обходят интуитивно, если в обсуждении или формулировке задачи использовались отглагольные существительные.

От этой ошибки на уровне интуиции привиты те, кто писал на Prolog или Lisp. Это, кстати, одна из причин, почему это работает у Эванса, но не сработает у вас.

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

## Ограничиваться только предметной областью задачи ##

В радикальной форме выглядит так: «‎Насаждение доменной модели разработчикам всех уровней системы».

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

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

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

> Одна только изоляция бизнес-логики никак не облегчает добавление новых функций и исправление реализации старых.

А все потому, что техническая часть все еще каша. Просим заказчика потянуть еще годик?

## Строить модели по исходным формулировкам ##

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

Пример из педагогики (утащил у М. Крыловой).

Проблемы с математикой из-за противня.
Дано:

  • Девочка из 4 класса.
  • Задание по математике про дроби и пирожки.
  • Подобные задачи решались с успехом самостоятельно.

Найти: Почему именно эта задача стала трудна?

Решение: Через 10 минут мучений была вскрыта проблема: «‎А что такое противень?» На удивление,  ответ о назначении противня девочке помог. Проблема была устранена и задача легко решилась.

Можно посмеяться над девочкой, а можно посмотреть в переписку с аналитиком и увидеть в девочке себя.

Первый шаг при моделировании — очистить задачу от таких «‎противней», иначе модель будет перегружена деталями и левыми объектами, которые вообще не имеют отношения к задаче.

Если пытаться моделировать «‎как есть», то в модели появятся противень, духовка, режимы выпекания и т.д.

А нужно-то было сделать калькулятор.

Заказчик ни при чем — он пекарь. Тут вина программиста, который побежал моделировать домен, не очистив формулировку (как он это уже делал в школе, на уроках физики).

## UML ##

«‎Моделирование — это про UML?»

Нет.

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

Для описания моделей, UML одновременно излишне перегружен и крайне ограничен. Другая его проблема — стандарт порожден из Java-образноного понимания ООП, которое работает только в пределах самой Java и то — с попеременным успехом.

Попытка использовать UML для описания моделей — гарантированный провал.

## Слоистая архитектура ##

Снова вернемся к книге Эванса.

Описывая детали технического контекста, он постоянно упоминает слои. Однако не будем забывать, что слои — это подход Java фреймворков, который не работает за их пределами.

Использовать Java примеры Эванса — гарантированно провалить архитектуру.

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

То есть, мы на все смотрим как на паутину задач, решение которых приводит к нужному результату. Попытки раскидать задачи «‎по слоям» превращаются в игру в пятнашки с постоянным нарушением технического контекста.

## Coda ##

Каждому контексту по модели.
Каждой модели свободное представление.
Каждой задаче по решению.
Каждому решению по реализации.
Объектно-ориентированное описание бизнес-процессов  в мусорку.

Статья автора издательства LIVREZON.
Следующая статья
Педагогика и образование
Рефлексируйте как рыцари, или опыт использования самоанализа в вузовской практике
Как научить студентов фиксировать данные о своей деятельности и развивать навыки самоанализа? Этот вопрос особенно актуален для исследователей, стремящихся смотреть на мир шире и находить закономерности, незаметные на первый взгляд. В своей статье я, профессор Виталий Борисенко, делюсь опытом внедрения навыков самоанализа через регулярные записи и рассказываю о том, как мы с моими студентами взяли за основу легенду о рыцарях Круглого стола для формирования эффективной привычки. Меня зовут Виталий Павлович Борисенко, я профессор-экспериментатор в высшей шк...
Педагогика и образование
Рефлексируйте как рыцари, или опыт использования самоанализа в вузовской практике
Бизнес и экономика
Что делать, если не получилось делегировать? Схема передачи работы другому сотруднику
Бизнес и экономика
Решает ли бизнес-проблемы теория ограничений системы Элияху Голдратта?
Бизнес и экономика
«Производственная система Тойоты. Уходя от массового производства» – реферат: самое главное из книги Тайити Оно
Педагогика и образование
Психодиагностика по рисунку: не так страшен чёрный цвет, как его малюют
Livrezon-технологии
Интерфейс Photoshop: основная парадигма и базовые объекты
Livrezon-технологии
Исправляем ошибки при создании сайта личного архива
Livrezon-технологии
Курсовая работа здорового человека vs «Курсач курильщика»
Livrezon-технологии
Сайт личного архива: ошибки при создании
Livrezon-технологии
Интерфейс как форма выражения процедуры: как устроен калькулятор
Бизнес и экономика
Как социальная реклама сглаживает национально-религиозные противоречия?
Бизнес и экономика
PRотив насилия: как социальная реклама спасает детей?
Педагогика и образование
«Основы дефектологии» Л. С. Выготского: концентрированный реферат – самое главное из книги
IT
Apple Vision Pro: революция или чемодан без ручки?
IT
Парадигмы софтов для дизайна интерфейсов
Livrezon-технологии
Кто в доме wear the pants? Разбираем английскую идиому на стажировке YOUBE Club

Медиа

Комментарии (1)

Сотников Вадим 9:04:56 PM 3/15/2020
Пользователь

На хабре читал, что в паре с Эвансом надо читать "Implementing Domain-Driven Design"от Vaughn Vernon.