Комментарии 15
DDD - это таинственный зверь, про которого пишут тысячи статей, пересказывая вновь и вновь одно и тоже из статьи в статью про Bounded Contexts, Aggregates, Ubiquitous Language и рисуя схемы гексагональной архитектуры, но при этом никто этого зверя в глаза не видел и не горит желанием выложить реальный проект с реальным решением проблем через DDD, где будет видно что ничего из этого в реальной жизни не работает, ну или наоборот все оценят и поймут как это круто и не нужно будет дальше писать тысячи статей. Но нет зачем что-то реализовывать, лучше про это писать.
-У тебя есть
картареальный пример проекта?-Лучше! У меня рисунок
картыгексагональной архитектуры.
DDD - это таинственный зверь...но при этом никто этого зверя в глаза не видел
Это не совсем так. DDD — не "волшебная таблетка", а набор практик для сложных доменов, где бизнес-логика запутана и меняется. Его редко применяют "по учебнику", потому что:
Каждый домен уникален, и решения адаптируются под контекст.
Реальные примеры часто закрыты NDA (банки, и тд).
Пример открытых проектов:
Домены в системах типа Apache Isis (хотя это уже "тяжелая артиллерия").
Но да, многие статьи действительно поверхностны, т.к. авторы пересказывают термины, не погружаясь в суть. Это проблема не DDD, а качества контента или той аудитории, для которой пишется контент.
-У тебя есть
картареальный пример проекта?-Лучше! У меня рисунок
картыгексагональной архитектуры.
Схемы - это лишь инструмент для визуализации. Суть в том, чтобы:
Изолировать доменную логику от инфраструктуры (базы, фреймворки)
Упростить тестирование
Пример: если вы отделяете логику оплаты заказа от способа оплаты (Робокасса, эквайринг), это уже элемент гексагонального подхода. Многие так делают, даже не зная терминов.
Согласен, что вокруг DDD много шума. Но его ценность - не в модных терминах, а в фокусе на смысле, а не на технологиях. Если у вас есть примеры, где DDD не сработал — давайте обсудим! Мне самому интересно, где границы его применимости. Именно поэтому я и писал эту стать. Именно поэтому я и рисовал красивые графики. И именно поэтому я отвечаю подробно ваш комментарий.
Если у вас есть примеры, где DDD не сработал — давайте обсудим!
У меня есть.
ddd или ddd-like организация кодовой базы очень хорошо помогает в монолитах или в приложениях с сложной логикой. Более того это повышает культуру разработки, а также ускоряет разработку "на длинной дистанции".
Однажды научившись писать "хорошо" сложно смотреть на спагетти код коллег по цеху, жирные контроллеры, размазывание бизнес логики по всем уголкам проекта, тот же mvc и тд.
С другой стороны, ddd не везде применим, например в тех же микросервисах может выглядеть как оверхед, хотя мне проще даже микросервисы организовывать в ddd стиле тк получается единый подход к работе с кодовой базой, со всеми вытекающими плюсами от этого.
Но мне непонятен хайп на хабре на тему ddd который разгоняется в последнее время. Ведь это не что-то, что "открыли вчера". Люди десятки лет уже пишут приложения подобным образом и ничего нового в этом нет, но публика видимо "хватает" коли подобный некро-баяно-постинг заходит в массы.
А вы в курсе сколько штраф по договору за такие исходники?
Вообще ddd 20 лет в обед, это уже давно не хайп а стандарт для некоторых
Работал над переходом с легаси на DDD. Тогда я понял что у всех свое понятие senior-разработчика, DDD, ООП и еще много чего. По сути все сводится к тому какую конкретную реализацию технологии смогут состряпать ответственные лица
Как-то пришлось работать в проекте с DDD подходом на php, все было настолько сложно и запутанно (15 лет в разработке). вроде бы цель упростить поддержку проекта, но в итоге все становится намного сложнее. Пока думаю единственное что может быть полезным из DDD это ограниченный контекст.
Пока думаю единственное что может быть полезным из DDD это ограниченный контекст.
Абсолютно согласен, даже без полного погружения, можно брать на вооружения отдельные практики:
Единый язык (Ubiquitous Language) снижает риски недопонимания между разработчиками и бизнесом
И отдельно добавлю про Bounded Contexts, который поможет дробить монолиты на микросервисы
Bounded Contexts можно провести множеством разных способов. Даже список метрик устану перечислять, которые можно оптимизировать выбором границы.
Я вот выбирал как-то из 3х вариантов. Тут нет полного ответа, но логика понятна:
https://LLMshare.syntxai.net/bf727f63-55f9-d062-1f2817af
А потом даже экономическое обоснование выбора сделал.
Работаю на проекте, где сейчас в одном из модулей внедрен ддд
Цель ясна - упростить разработку и поддержку, разделить на слои и все такое
Вот только небольшие правки выливаются в МР с 20 файлами из-за чудовищного количества абстракций
Единый язык (Ubiquitous Language)
Говорите на одном языке с бизнесом. Если бизнес говорит "клиент", то и в коде должно быть "клиент", а не "user" или, что ещё хуже, "entity". Это кажется очевидным, но вы удивитесь, если чекните свои репозитории, можете найти, что client = user = human
Я предпочитаю не вмешиваться в язык. Если бизнес говорит клиент, то в коде у меня будет клиент русскими буквами. А если будет сложный медицинский термин, то в коде будет он на языке бизнеса, то есть на русском или на латыни если бизнес так изъясняется.
DDD хорош тем, что его можно адаптировать частично по необходимости. Так паттерны DDD давно применяются в ORM и DI фреймворках. А DDD Lite вполне применяется, когда команда перестает вывозить когнитивную сложность. Хайпа нет, есть пост-DDD.
Domain-Driven Design (DDD) — Как сделать архитектуру запутанной