Про DDD пару слов

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

Про скелеты

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

Глупо будет утверждать, что такой подход не работает. Но после знакомства с книжкой Фаулера по рефакторингу я стал использовать другой способ проектирования.

Альтернатива

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

Если приложение не делает то, что от него требуется, то его нельзя релизить. Если оно делает все, что от него требуется, то не очень важно, сколько там табличек, классов и микросервисов. Хотя, конечно, чем меньше, тем лучше.

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

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

Преимущества

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

Пример

В ДДД-книжке Эванс приводил пример, где маршрут может быть спроектирован либо как последовательность точек, либо как последовательность переходов между ними. Какая реализация лучше? Зависит от поведения, от связей в коде. Именно поэтому решение может быть полезно принимать уже после того, как вы уже посмотрите на поведение, на код и связи в нём.

И именно поэтому половина оригинальной книжки по тдд - это примеры рефакторинга доменных моделей. Никто не ожидает от вас, что вы сразу догадаетесь, какая доменная модель подойдёт вам.