@AG1017 апр 2020 в 09:39

Крошка сын к отцу пришел и спросила кроха: что такое DDD? Но так, чтобы я понял

9 мин

14K

Анализ и проектирование систем * Программирование * Проектирование и рефакторинг * Веб-разработка * Управление разработкой *

+11

Комментарии 13

@Guzergus 17 апр 2020 в 12:19

Одна из ишью с ddd, для меня, в том что многие люди в моей сфере (C#/Java) считают, что ddd это когда у вас интерфейсы IAggregateRoot, умные объекты и прочее. В связи с этим вокруг ddd витает дух «сложной архитектуры», о котором в статье и упоминается.
На мой взгляд, ddd не об этом. Оно о том, чтобы тесно работать с бизнесом, понимать его процессы, вникать в них. Искренне не понимаю, почему во многих проектах внедрение ddd обязательно требует невероятного усложенения архитектуры и огромной башни абстракций. Профит от минимального взаимодействия с клиентом или ЦА своего продукта (пообщаться онлайн, посмотреть на процессы в реальности, etc) в разы выше, чем все эти абстракции поверх абстракций.
Собственно, если память не изменяет, Эванс упоминал недавно, что жалеет о фокусе в своей книге и что ubiquitous language + bounded context куда важнее, чем более технические паттерны.

@AG10 17 апр 2020 в 13:55

Видимо поэтому Вернон в Красной книге и начинает со стратегических паттернов.
Но на мой взгляд не стоит недооценивать и сложность создания UL и BC. Я думаю UL — это нечто гораздо большее чем «минимального взаимодействия с клиентом или ЦА своего продукта»(хотя это уже лучше, чем ничего), а грамотное выделение автономных BC — это вообще отдельная наука.

@AG10 18 апр 2020 в 04:16

Я так понимаю под «башней абстракций» вы подразумеваете тактические паттерны DDD. Как вы считаете для какой цели они были созданы и когда, на ваш взгляд, их применение действительно оправдано?

@Guzergus 18 апр 2020 в 15:56

На всякий случай уточню, что конкретно я имел в виду — паттерны repository, factory, service, Aggregate Root, etc. Помимо самих паттернов, в моей основной технологии также любят их более «сложные» варианты — repository мы обязательно делаем generic потому что писать под добавления под каждую сущность это слишком, фабрики делаем абстрактными т.к. мало ли что и так далее. Всё это закидываем, разумеется, в IoC контейнер и получаем минимум 7 проектов в solution даже если пишем простейший микросервис.

для какой цели они были созданы

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

и когда, на ваш взгляд, их применение действительно оправдано?

Скажу сразу, оценить в объективных критериях это крайне сложно, поэтому в итоге всё сводится к «оправдано там, где оправдано».
На мой взгляд, эти паттерны крайне часто используют слишком рано. Я не вижу смысла в generic repository, если у вас нет такой же дженерик логики работы с сущностями. Пример, где она есть — какая-нибудь CMS, в которой пользователь может сам создавать сущности и работать с user-defined fields.

Мой основной посыл был не против этих паттернов как таковых, а скорее к тому, что грамотное DDD вполне может существовать без них. Более того, я придерживаюсь точки зрения, что DDD не обязательно должно быть в ООП парадигме. Выразите свои бизнес-правила в языке чистых функций, discriminated unions и у вас получится понятная и простая модель. Не обязательно иметь в коде классы bounded context, aggregate root, repository чтобы следовать DDD.

@AG10 20 апр 2020 в 06:44

спасибо за развернутый ответ. еще пара вопросов)

есть среди тактических паттернов DDD те, которые на ваш взгляд точно не переусложнят и их оправданно использовать с самого начала?
есть ли открытые репозитории, в которых можно посмотреть примеры реализации идей DDD на функциональных языках?

@Guzergus 20 апр 2020 в 22:08

есть среди тактических паттернов DDD те, которые на ваш взгляд точно не переусложнят и их оправданно использовать с самого начала?

Признаюсь, не так сильно вникал в DDD, поэтому все паттерны сходу не вспомню. Если считать immutable value object паттерном — то, например, он. Стараюсь в своих рабочих и домашних проектах делать immutable объекты везде, где это можно и не вызывает инфраструктурных проблем.
Если говорить о коммерческих проектах, то так же используем CQRS. (Он, строго говоря, не DDD паттерн, но для общей картины упомяну)

есть ли открытые репозитории, в которых можно посмотреть примеры реализации идей DDD на функциональных языках?

Боюсь что именно коммерческих энтерпрайз проектов в открытом доступе не видел, но есть интересная серия статей на эту тему:
fsharpforfunandprofit.com/series/designing-with-types.html
Особое внимание я обратил бы на docs.microsoft.com/en-us/dotnet/fsharp/language-reference/discriminated-unions
Очень часто возникали в работе задачи, где юнионы отлично подошли бы для моделирования нескольких возможных результатов, но т.к. я не пишу на F#, приходилось использовать enum и жить без подсказок компилятора и строгой типизации.

@VanquisherWinbringer 4 мая 2020 в 11:23

Хм, тут скорее дело в том что люди часто путают Onion архитектуру которая про вот Rository и все остальное и DDD подход к разработке.

@Ekstrem 13 мая 2020 в 13:56

Они связаны косвенно. Луковая и гексогональная идеально подходят для проработки доменной модели (реализации тактических паттернов). Репозиторий так же относится к тактическим паттернам DDD.

Несмотря на то что М.Симан нехорошо отзывался о гексогональной архитектуре, как по мне, именно её удобнее всего использовать для архитектур доменной модели.