А как же реализовывать асинхронщину? Слашал, в доменных моделях ей не место. Но вот в примере есть проверка, что блюда с таким именем еще нет, у нас нет кнокретной реализации, просто иньерфнйс исппользуется. Но в конкретной реализации, когда inmemorystogare заменится на db, может понадобиться сделать ассинхронный запрос к хранилищу. И как это будет выглядеть?

46:50 странное замечание про накладность собрать людей на 30 минут или час. Если что, переделка чего-либо на каждом последующем этапе кратно дороже предыдущего. Лучше собрать экспертов предметной области на этапе проектирования, чем переделывать додумки разработчиков после внедрения.

Обрежьте "ААААААААААААААААААААААА". Спикеры-хуикеры. Э, А, ЭМ. Блять, как это слушать?

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

2:25 А почему RabbitMQ выковыриваете?

На 1:35:55 запросы в базу в цикле делаются. Невероятно чистый код! Превосходная производительность! Браво, пишите ёще!

47:26 - парень Евгений говорит, что ничего страшного нет, чтобы расширить интерфейс ради 1 объекта, хотя другим оно не надо --> ничего страшного. Как ничего страшного? А внести изменения в конструкторы во всех местах? Или в сигнатуры методов. Что-то непонятно.

Интересное обобщение, но не на все случаи жизни)

чувак просто прочитал книгу и ее пересказал - ничего нового.

Какой молодец! Создал фреймворк, молодец! Только где его посмотреть?

папка в проекте это не ген план. ген план это диаграмvа use case, из которой например и будет понятно назначение приложения :)

Звук это инфраструктурный слой? ЕРЕТИК

Я услышал много про чистую архитектуру и почти ничего про DDD. Такое чувство, что спикеры пытаются подсунуть чистую архитектуру под видом DDD.

Чушь, до конца не досмотрел не хватило терпения вода какая-то

У нас не очень много времени потому потратим 30 минут что бы посмотреть на дибильные вопросы результатом которых, о боже, не вероятно, домен является самым важным. РАНЬШЕ думал что самое главное это фреймворк которые раз в год выходит новый

Некорректная связь между ген. планом и структурой каталогов приложения. Вместо этого стоило бы использовать UML диаграммы тогда уж.

интересно послушать, спасибо

Шикарная подача

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

Сергею огромное спасибо🙏

когда показывали класс Menu, упомянули поле version, которое используется для оптимистической блокировки. И тут у меня сразу дисонанс, потому что это поле явно не относится бизнес-домену Menu, а относится к решению проблемы конкуретности в бд. Это в целом норм, или не норм? Или приходится идти на такого рода уступки? Если это действительно проблема, то можно ли ее решить?

Все-таки затянуто, хотелось бы пободрее и повеселее :) Пример, видимо, должен поразить всех тех, кто еще подумывает о чистоте архитектуры. Если для трех таблиц и пяти экранных форм нужно сооружать вот это вот всё, то что же нас ждет в действительно сложной многодоменной ERP?! Теперь о насущном. DDD заточен под имитационное моделирование (объекты активны, обладают поведением, а о "персистентности" можно вообще не думать). Энтерпрайз - это автоматизация информационных систем (сущности пассивны, но почти все долгохранимы, ими манипулируют люди через процессы). То есть подход должен был бы быть с другого конца (привет SADT и IDEF0). Ну и очевидное: все эти getByXXX работают только для простых CRUD-ов. Первый же dashboard с десятком панелей уровня "топ 10 заказов за 5 дней по товарам группы скоропортящихся среди клиентов с оборотом более 1М в месяц" снесет абстракцию к чертовой бабушке, как неадекватную. Рассуждения про СУБД, как про устройство ввода-вывода (в котором, однако, нужно дублировать "констрейнты" домена sic!) несколько забавны, если знать, что уровень абстракции объектной и реляционной моделей одинаков. В общем, как и другие люди 25 лет назад вы снова приводите к выводу, что ООП в 1960-е годы не зря появилось для решения задач моделирования, а промышленные СУБД в те же годы (а не в 80-е, как авторы ошибочно дезинформировали слушателя) - для автоматизации ИС. Выводов не будет, спасибо за обеденное видео.

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

Херню полную несут. После первых 10 мин начало тошнить.

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

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

Структура папок и файлов - это не чертежи, это уже реализация. "Чертежи" приложения - это какие-нибудь UML-схемки, диаграмки. А из них уже более чем понятно что за приложение. Мысль годная, сравнение - бестолковое.

Презентация по ссылке больше не доступна, перезалейте, пожалуйста.

А для автора русский язык родной? Очень тяжело получается подбирать слова и формулировать мысли

На 11:45 заслуженный лайк за отличное сравнение. Мне очень понравилось, о многом задумался.

Топ-контент! С примерами на практике - всё как положено.

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

Контент - годнота! Да ещё с такими примерами, где прям контексты - по каталогам!

Вопросы - говно)) Никто из вопрошающих в суть так и не въехал 😁

Сергей какой-то мудак просто)

Не так всё однозначно не слайде "Чем придётся заплатить", имхо, ключевой момент всей этой чистой архитектуры. Тк в реальном проекте так и выходит: тут не1 однозначно, там не однозначно, 10 раз не однозначно, и вот мы уже получили винегрет из "слоистой" и чистой архитектуры... Пол года без БД? Да вы о чем? Нас после этого всех разгонят. Все проекты делаются по принципу "нужно было ещё вчера", если ты через неделю не покажешь работающую админку заказчику -- будешь потом на собеседовании рассказывать про чистую архитектуру и пол года без бд! 🤣🤣🤣 я конечно утрирую, но и вы тут перегнули палку, надо было сценарий лучше прописать ;) Пример с театром -- сильно надуманный, немного портит впечатление, сразу хочется поспорить :) А так видео хорошее, спасибо! Есть пара новых моментов о чем подумать :) Правда лучше смотреть на скорости 1,5х :))))

Спасибо, я думаю надо было взять пример который бы все тонкости затрагивал. Ждем новый мастер класс версии 2 😅, где раскрываются все вопросы 😊

Огромное спасибо! Подача - огонь.

отличная идея! а как секция сценарии использования выглядят?

шина достает агрегаты?

объекты значения можно писать в БД как отдельный тип данных, doctrine позволяет такое

Опа, Бухаров, а нам не скинул видос -_-

Спасибо, великолепно!🎉

Чем дольше смотришь этот ролик, тем чаще вспоминаешь, как он кинотеатр просто театром называл в начале.

Очень странно сравнивать структуру проекта и строительный чертеж. Я думаю, если бы посмотрели на файловую структуру проекта, вы бы тоже ничего не поняли. Правильно в данном случае было бы смотреть на архитектурные документы и диаграммы. А вот там бы как раз все было бы понятно. Понятно, о чем идет речь, но аналогия под сильным воздействием литературной гиперболы.

Я прям плакать начинаю, когда представляю длину файла UseCaseConfiguration.kt для реального ентерпрайс проекта, в котором хотя бы 100+ безнес задач. ))))

просто примеры, никаких конкретных объяснений сущностям и почему именно так, базовые знания

Очень мало полезной информации про Event Storming, все остальное вода, не тратьте время

И вот например надо с фронта указать какой entity graph использовать чтобы вытянуть сущность, не писать же на каждый вариант find по методу ? У нас сущность мапится в дто, и лези поля в дто будут нулами, что удобно, не режется производительность лишний раз. Но это уже какая-то не очень чистая архитектура получается, когда приходится графы так передавать. И таких моментов много, что нивелирует чистоту впринципе

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