Чистая архитектура и Domain-Driven Design 

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

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

Спасибо! Очень интересно и ясно подали идею! 👍

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

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

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

Спасибо!

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

В докладе говорится и о чистой архитектуре, и о DDD, и о модульном монолите, и о распиливании на микросервисы. В результате и обо всем сразу, и ни о чем конкретно. Лучше было взять одну тему, но рассказать ее подробно. Не прозвучал главный тезис, описывающий взаимоотношения чистой архитектуры и DDD: чистая архитектура про то, как сделать отдельно взятый баундед контекст, DDD - как большую систему разделить на эти контексты и настроить взаимодействие между ними. Про чистую архитектуру слишком слабо, показанный игрушечный пример не дает ответов на вопросы, которые возникают в реальных проектах: - куда девать логику, которая не запихивается в один агрегат? (например, среди всех entities у одной установить IsDefault, а у всех остальных сбросить) - как переиспользовать между юскейсами дублирующуюся логику - как лучше реализовать юскейсы, один класс на каждый юскейс, или сервис, в котором реализованы все юскейсы для агрегата - контроллеры, обязательно ли их выделять в отдельный слой - в показанном примере юскейсы (RemoveMealFromCartUseCase) находятся в одном слое с интерфейсами инфраструктуры (CartExtractor), этот косяк есть как в книге дяди Боба, так и во всех реализациях чистой архитектуры, которые я видел. Практичнее выносить их в отдельный компонент, но тогда ломается правило зависимостей, согласно которому наружный слой может использовать любые внутренние, но контролеры не должны ходить в инфраструктуру в обход юскейсов. Прозвучал тезис, что в случае с чистой архитектурой нужно создавать больше классов, чем в какой-то другой (видимо слоистая имелась ввиду). Но не показано примера, на котором это видно. Ну и зачем были нужны маркетинговые враки типа "полгода работы без базы", "по щелчку пальцев с десктопа на веб" я вообще не понимаю, лучше бы закончили пораньше, а не развозили болтовню на 2 часа.

Офигенные ребята, очень бодро и весело рассказывают! Но когда дело дошло до кода - началась каша, я окончательно запутался, где что и кем используется, заплакал и ушел)

вы можете обрезать начало где идут понты?

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

работали вместе с Сергеем в РТЛабсе)

шикарная подача!!

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

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

Фух не так просто выиграть Евгения в гляделки, но я это сделал

Объясните, пожалуйста, как блюдо добавляется в меню?

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

Спасибо! Очень интересно! Также понравилась книга Get Your Hands Dirty on Clean Architecture by Tom Hombergs , там немного по другому структура папок сделана, но идеи те-же

Где вы джима керри нашли?

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

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

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

Евгену тяжело пришлось роль играть несведущего))

Спасибо!!!

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

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

Очень устал от понтов, но на том что базы затлчены современные на крутилки чет не выдержал

9:25 осуждаем

Про анемичную модель - не убедил!

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

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

Видно что Сергей Бухаров умеет донести инфу слушателю , приятно его слушать

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

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

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

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

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

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

If you are experts, why you would need to play and simulate that you do not understand what you are talking about? Feels like you lack your own ideas and lot of first minutes of the presentation is just copied the idea of Robert Martin anyway. Why you need to pretend? Talk to the point, otherwise those who already know they just waste time, as you claim you are such an experts. Right after 15 min, a lot of insignificant information, and that playing just pisses me off. Robert Martin is the best, please do not try to copy his content as your own, integrate in your own ideas. And try to be more humble, the egoism level is quite high here (why i would care what books you have around with Uncle Bobs book, whose shelf it is anyway?), like i should be proud that you play chess. It is the same as those people who put their photos of their marriage and with their newborn babies, and cats and dogs in costumes and party time pictures in internet. It feels like you want to be heard (internet is full of this stuff already). This is not the way, because it looks like 2 clowns talking without any logical intent.

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

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