Comments 13
Одна из ишью с ddd, для меня, в том что многие люди в моей сфере (C#/Java) считают, что ddd это когда у вас интерфейсы IAggregateRoot, умные объекты и прочее. В связи с этим вокруг ddd витает дух «сложной архитектуры», о котором в статье и упоминается.
На мой взгляд, ddd не об этом. Оно о том, чтобы тесно работать с бизнесом, понимать его процессы, вникать в них. Искренне не понимаю, почему во многих проектах внедрение ddd обязательно требует невероятного усложенения архитектуры и огромной башни абстракций. Профит от минимального взаимодействия с клиентом или ЦА своего продукта (пообщаться онлайн, посмотреть на процессы в реальности, etc) в разы выше, чем все эти абстракции поверх абстракций.
Собственно, если память не изменяет, Эванс упоминал недавно, что жалеет о фокусе в своей книге и что ubiquitous language + bounded context куда важнее, чем более технические паттерны.
На мой взгляд, ddd не об этом. Оно о том, чтобы тесно работать с бизнесом, понимать его процессы, вникать в них. Искренне не понимаю, почему во многих проектах внедрение ddd обязательно требует невероятного усложенения архитектуры и огромной башни абстракций. Профит от минимального взаимодействия с клиентом или ЦА своего продукта (пообщаться онлайн, посмотреть на процессы в реальности, etc) в разы выше, чем все эти абстракции поверх абстракций.
Собственно, если память не изменяет, Эванс упоминал недавно, что жалеет о фокусе в своей книге и что ubiquitous language + bounded context куда важнее, чем более технические паттерны.
+6
Видимо поэтому Вернон в Красной книге и начинает со стратегических паттернов.
Но на мой взгляд не стоит недооценивать и сложность создания UL и BC. Я думаю UL — это нечто гораздо большее чем «минимального взаимодействия с клиентом или ЦА своего продукта»(хотя это уже лучше, чем ничего), а грамотное выделение автономных BC — это вообще отдельная наука.
Но на мой взгляд не стоит недооценивать и сложность создания UL и BC. Я думаю UL — это нечто гораздо большее чем «минимального взаимодействия с клиентом или ЦА своего продукта»(хотя это уже лучше, чем ничего), а грамотное выделение автономных BC — это вообще отдельная наука.
0
Я так понимаю под «башней абстракций» вы подразумеваете тактические паттерны DDD. Как вы считаете для какой цели они были созданы и когда, на ваш взгляд, их применение действительно оправдано?
0
На всякий случай уточню, что конкретно я имел в виду — паттерны 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.
для какой цели они были созданы
Как и все остальные паттерны, для упорядочивания кода, разделения ответственностей, создания какой-никакой абстракции, чтобы не читать чистый SQL там, где хотелось бы просто понять логику.
и когда, на ваш взгляд, их применение действительно оправдано?
Скажу сразу, оценить в объективных критериях это крайне сложно, поэтому в итоге всё сводится к «оправдано там, где оправдано».
На мой взгляд, эти паттерны крайне часто используют слишком рано. Я не вижу смысла в generic repository, если у вас нет такой же дженерик логики работы с сущностями. Пример, где она есть — какая-нибудь CMS, в которой пользователь может сам создавать сущности и работать с user-defined fields.
Мой основной посыл был не против этих паттернов как таковых, а скорее к тому, что грамотное DDD вполне может существовать без них. Более того, я придерживаюсь точки зрения, что DDD не обязательно должно быть в ООП парадигме. Выразите свои бизнес-правила в языке чистых функций, discriminated unions и у вас получится понятная и простая модель. Не обязательно иметь в коде классы bounded context, aggregate root, repository чтобы следовать DDD.
0
спасибо за развернутый ответ. еще пара вопросов)
- есть среди тактических паттернов DDD те, которые на ваш взгляд точно не переусложнят и их оправданно использовать с самого начала?
- есть ли открытые репозитории, в которых можно посмотреть примеры реализации идей DDD на функциональных языках?
0
есть среди тактических паттернов 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 и жить без подсказок компилятора и строгой типизации.
0
Хм, тут скорее дело в том что люди часто путают Onion архитектуру которая про вот Rository и все остальное и DDD подход к разработке.
0
Они связаны косвенно. Луковая и гексогональная идеально подходят для проработки доменной модели (реализации тактических паттернов). Репозиторий так же относится к тактическим паттернам DDD.
Несмотря на то что М.Симан нехорошо отзывался о гексогональной архитектуре, как по мне, именно её удобнее всего использовать для архитектур доменной модели.
0
У lightbend есть видеокурс по реактивному программированию, одна из частей посвящена DDD. Рекомендую, пока ещё пару месяцев бесплатно.
0
Олдфаги припомнят Data Display Debugger (https://www.gnu.org/software/ddd/)
0
Sign up to leave a comment.
Крошка сын к отцу пришел и спросила кроха: что такое DDD? Но так, чтобы я понял