В докладе говорится и о чистой архитектуре, и о DDD, и о модульном монолите, и о распиливании на микросервисы. В результате и обо всем сразу, и ни о чем конкретно. Лучше было взять одну тему, но рассказать ее подробно. Не прозвучал главный тезис, описывающий взаимоотношения чистой архитектуры и DDD: чистая архитектура про то, как сделать отдельно взятый баундед контекст, DDD - как большую систему разделить на эти контексты и настроить взаимодействие между ними. Про чистую архитектуру слишком слабо, показанный игрушечный пример не дает ответов на вопросы, которые возникают в реальных проектах: - куда девать логику, которая не запихивается в один агрегат? (например, среди всех entities у одной установить IsDefault, а у всех остальных сбросить) - как переиспользовать между юскейсами дублирующуюся логику - как лучше реализовать юскейсы, один класс на каждый юскейс, или сервис, в котором реализованы все юскейсы для агрегата - контроллеры, обязательно ли их выделять в отдельный слой - в показанном примере юскейсы (RemoveMealFromCartUseCase) находятся в одном слое с интерфейсами инфраструктуры (CartExtractor), этот косяк есть как в книге дяди Боба, так и во всех реализациях чистой архитектуры, которые я видел. Практичнее выносить их в отдельный компонент, но тогда ломается правило зависимостей, согласно которому наружный слой может использовать любые внутренние, но контролеры не должны ходить в инфраструктуру в обход юскейсов. Прозвучал тезис, что в случае с чистой архитектурой нужно создавать больше классов, чем в какой-то другой (видимо слоистая имелась ввиду). Но не показано примера, на котором это видно. Ну и зачем были нужны маркетинговые враки типа "полгода работы без базы", "по щелчку пальцев с десктопа на веб" я вообще не понимаю, лучше бы закончили пораньше, а не развозили болтовню на 2 часа.
Да, наш пример относительно игрушечный, но боевой код с прода мы показать не можем. Это обзорная лекция и все подводные камни за два часа разобрать просто нереально. О взаимоотношении чистой архитектуры и DDD мы говорим на 40:21. ЧА - для выделения модулей, в том числе отделение техники от бизнеса, а также техники между собой, DDD - добавляет модульность с точки зрения бизнеса при помощи ограниченных контекстов. Всё что мы рассказываем взято исключительно из личного опыта и практики коллег. Отчасти мы показываем это на нашем примере, но похожий пример про базу данных можно увидеть в книге Р. Мартина «Чистая Архитектура» - часть V, глава 17. Fitnesse.
А как же реализовывать асинхронщину? Слашал, в доменных моделях ей не место. Но вот в примере есть проверка, что блюда с таким именем еще нет, у нас нет кнокретной реализации, просто иньерфнйс исппользуется. Но в конкретной реализации, когда inmemorystogare заменится на db, может понадобиться сделать ассинхронный запрос к хранилищу. И как это будет выглядеть?
Офигенные ребята, очень бодро и весело рассказывают! Но когда дело дошло до кода - началась каша, я окончательно запутался, где что и кем используется, заплакал и ушел)
Очень странно сравнивать структуру проекта и строительный чертеж. Я думаю, если бы посмотрели на файловую структуру проекта, вы бы тоже ничего не поняли. Правильно в данном случае было бы смотреть на архитектурные документы и диаграммы. А вот там бы как раз все было бы понятно. Понятно, о чем идет речь, но аналогия под сильным воздействием литературной гиперболы.
47:26 - парень Евгений говорит, что ничего страшного нет, чтобы расширить интерфейс ради 1 объекта, хотя другим оно не надо --> ничего страшного. Как ничего страшного? А внести изменения в конструкторы во всех местах? Или в сигнатуры методов. Что-то непонятно.
Спасибо за публикацию спитча, было интересно, но я тоже не успел осознать весь кода из вашего примера. Понимаю что сжатое время, но может один метод новый в application модуле написать и это как-то улучшит понимание. Исходный код можно посмотреть только оплатив курс? :)
когда показывали класс Menu, упомянули поле version, которое используется для оптимистической блокировки. И тут у меня сразу дисонанс, потому что это поле явно не относится бизнес-домену Menu, а относится к решению проблемы конкуретности в бд. Это в целом норм, или не норм? Или приходится идти на такого рода уступки? Если это действительно проблема, то можно ли ее решить?
Иногда технические вещи (гуиды, версии) протекают в домен. Как по мне - не стоит с этим перебарщивать, но и избавляться во что бы то ни стало не надо, особенно если это некий единный подход в проекте.
И вот например надо с фронта указать какой entity graph использовать чтобы вытянуть сущность, не писать же на каждый вариант find по методу ? У нас сущность мапится в дто, и лези поля в дто будут нулами, что удобно, не режется производительность лишний раз. Но это уже какая-то не очень чистая архитектура получается, когда приходится графы так передавать. И таких моментов много, что нивелирует чистоту впринципе
Не так всё однозначно не слайде "Чем придётся заплатить", имхо, ключевой момент всей этой чистой архитектуры. Тк в реальном проекте так и выходит: тут не1 однозначно, там не однозначно, 10 раз не однозначно, и вот мы уже получили винегрет из "слоистой" и чистой архитектуры... Пол года без БД? Да вы о чем? Нас после этого всех разгонят. Все проекты делаются по принципу "нужно было ещё вчера", если ты через неделю не покажешь работающую админку заказчику -- будешь потом на собеседовании рассказывать про чистую архитектуру и пол года без бд! 🤣🤣🤣 я конечно утрирую, но и вы тут перегнули палку, надо было сценарий лучше прописать ;) Пример с театром -- сильно надуманный, немного портит впечатление, сразу хочется поспорить :) А так видео хорошее, спасибо! Есть пара новых моментов о чем подумать :) Правда лучше смотреть на скорости 1,5х :))))
Структура папок и файлов - это не чертежи, это уже реализация. "Чертежи" приложения - это какие-нибудь UML-схемки, диаграмки. А из них уже более чем понятно что за приложение. Мысль годная, сравнение - бестолковое.
У нас не очень много времени потому потратим 30 минут что бы посмотреть на дибильные вопросы результатом которых, о боже, не вероятно, домен является самым важным. РАНЬШЕ думал что самое главное это фреймворк которые раз в год выходит новый
Спасибо! Очень интересно! Также понравилась книга Get Your Hands Dirty on Clean Architecture by Tom Hombergs , там немного по другому структура папок сделана, но идеи те-же
Regarding books, the content of Matthias Noback is very good which is going in the right direction to implement Clean Architecture. Also Implementing Domain Driven Design and Growing Object-Oriented Software Guided By Tests.
Ребята, вы говорите что анемичная модель - это плохо, но аргументы в защиту этого утверждения приходится придумывать на ходу. Вы уж простите, но это несерьезно. Если прочитаете это сообщение, можете оставить под ним более емкое обоснование своего тезиса.
Да, пожалуй, аргументы не самые убедительные, но вспомнить всё сразу оказалось довольно трудно. Мы планируем написать об этом подробнее в бложике. Опубликуем ссылку здесь.
Есть подозрение, что написав проект без чистой архитектуры, а с обычной продуманной архитектурой разницы будет ноль, просто программистам скучно. Если бы этот подход был лучше стандартного анемичного например, то он бы уже стал стандартом, как реактивное программирование на 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+ безнес задач. ))))
![Lp. Сердце Вселенной #60 РОЖДЕНИЕ ЛОЛОЛОШКИ [Финал] • Майнкрафт](http://i.ytimg.com/vi/YoR0pAV9FVQ/mqdefault.jpg)
![Просто о сложном - Domain Driven Design [ru] / Дмитрий Науменко](/img/n.gif)
Чем дольше смотришь этот ролик, тем чаще вспоминаешь, как он кинотеатр просто театром называл в начале.
На 1:35:55 запросы в базу в цикле делаются. Невероятно чистый код! Превосходная производительность! Браво, пишите ёще!
На 11:45 заслуженный лайк за отличное сравнение. Мне очень понравилось, о многом задумался.
Огромное спасибо! Подача - огонь.
Спасибо! Очень интересно и ясно подали идею! 👍
вы можете обрезать начало где идут понты?
Дак кажется тут только понты и есть все видео из них
Я перемотал понты
Видео без понтов - безпонтовое
😂😂😂 +1
ахаха беспонтовое@@Deletedeletedelete
В докладе говорится и о чистой архитектуре, и о DDD, и о модульном монолите, и о распиливании на микросервисы. В результате и обо всем сразу, и ни о чем конкретно. Лучше было взять одну тему, но рассказать ее подробно.
Не прозвучал главный тезис, описывающий взаимоотношения чистой архитектуры и DDD: чистая архитектура про то, как сделать отдельно взятый баундед контекст, DDD - как большую систему разделить на эти контексты и настроить взаимодействие между ними.
Про чистую архитектуру слишком слабо, показанный игрушечный пример не дает ответов на вопросы, которые возникают в реальных проектах:
- куда девать логику, которая не запихивается в один агрегат? (например, среди всех entities у одной установить IsDefault, а у всех остальных сбросить)
- как переиспользовать между юскейсами дублирующуюся логику
- как лучше реализовать юскейсы, один класс на каждый юскейс, или сервис, в котором реализованы все юскейсы для агрегата
- контроллеры, обязательно ли их выделять в отдельный слой
- в показанном примере юскейсы (RemoveMealFromCartUseCase) находятся в одном слое с интерфейсами инфраструктуры (CartExtractor), этот косяк есть как в книге дяди Боба, так и во всех реализациях чистой архитектуры, которые я видел. Практичнее выносить их в отдельный компонент, но тогда ломается правило зависимостей, согласно которому наружный слой может использовать любые внутренние, но контролеры не должны ходить в инфраструктуру в обход юскейсов.
Прозвучал тезис, что в случае с чистой архитектурой нужно создавать больше классов, чем в какой-то другой (видимо слоистая имелась ввиду). Но не показано примера, на котором это видно.
Ну и зачем были нужны маркетинговые враки типа "полгода работы без базы", "по щелчку пальцев с десктопа на веб" я вообще не понимаю, лучше бы закончили пораньше, а не развозили болтовню на 2 часа.
Да, наш пример относительно игрушечный, но боевой код с прода мы показать не можем. Это обзорная лекция и все подводные камни за два часа разобрать просто нереально.
О взаимоотношении чистой архитектуры и DDD мы говорим на 40:21. ЧА - для выделения модулей, в том числе отделение техники от бизнеса, а также техники между собой, DDD - добавляет модульность с точки зрения бизнеса при помощи ограниченных контекстов.
Всё что мы рассказываем взято исключительно из личного опыта и практики коллег. Отчасти мы показываем это на нашем примере, но похожий пример про базу данных можно увидеть в книге Р. Мартина «Чистая Архитектура» - часть V, глава 17. Fitnesse.
А как же реализовывать асинхронщину? Слашал, в доменных моделях ей не место. Но вот в примере есть проверка, что блюда с таким именем еще нет, у нас нет кнокретной реализации, просто иньерфнйс исппользуется. Но в конкретной реализации, когда inmemorystogare заменится на db, может понадобиться сделать ассинхронный запрос к хранилищу. И как это будет выглядеть?
Шикарная подача
Офигенные ребята, очень бодро и весело рассказывают! Но когда дело дошло до кода - началась каша, я окончательно запутался, где что и кем используется, заплакал и ушел)
Интересное обобщение, но не на все случаи жизни)
Спасибо!
Очень странно сравнивать структуру проекта и строительный чертеж. Я думаю, если бы посмотрели на файловую структуру проекта, вы бы тоже ничего не поняли. Правильно в данном случае было бы смотреть на архитектурные документы и диаграммы. А вот там бы как раз все было бы понятно.
Понятно, о чем идет речь, но аналогия под сильным воздействием литературной гиперболы.
Фух не так просто выиграть Евгения в гляделки, но я это сделал
(минуте к тридцатой)
работали вместе с Сергеем в РТЛабсе)
для меня самое сложное понять как выделить бизнес правила, должны ли мы сами их додумывать, или это просто описания требований заказчика?
47:26 - парень Евгений говорит, что ничего страшного нет, чтобы расширить интерфейс ради 1 объекта, хотя другим оно не надо --> ничего страшного. Как ничего страшного? А внести изменения в конструкторы во всех местах? Или в сигнатуры методов. Что-то непонятно.
Звук это инфраструктурный слой?
ЕРЕТИК
Где вы джима керри нашли?
Опа, Бухаров, а нам не скинул видос -_-
папка в проекте это не ген план. ген план это диаграмvа use case, из которой например и будет понятно назначение приложения :)
Видно что Сергей Бухаров умеет донести инфу слушателю , приятно его слушать
Спасибо за публикацию спитча, было интересно, но я тоже не успел осознать весь кода из вашего примера. Понимаю что сжатое время, но может один метод новый в application модуле написать и это как-то улучшит понимание. Исходный код можно посмотреть только оплатив курс? :)
когда показывали класс Menu, упомянули поле version, которое используется для оптимистической блокировки. И тут у меня сразу дисонанс, потому что это поле явно не относится бизнес-домену Menu, а относится к решению проблемы конкуретности в бд. Это в целом норм, или не норм? Или приходится идти на такого рода уступки? Если это действительно проблема, то можно ли ее решить?
Иногда технические вещи (гуиды, версии) протекают в домен. Как по мне - не стоит с этим перебарщивать, но и избавляться во что бы то ни стало не надо, особенно если это некий единный подход в проекте.
шикарная подача!!
И вот например надо с фронта указать какой entity graph использовать чтобы вытянуть сущность, не писать же на каждый вариант find по методу ? У нас сущность мапится в дто, и лези поля в дто будут нулами, что удобно, не режется производительность лишний раз. Но это уже какая-то не очень чистая архитектура получается, когда приходится графы так передавать. И таких моментов много, что нивелирует чистоту впринципе
для этих сценариев просто идеально подходит GraphQL (использовали на проде и это было шикарно)
Объясните, пожалуйста, как блюдо добавляется в меню?
Сравнение скрина фреймворка с чертежами, дикая дичь. Вы бы фото кирпича показали ещё... Или оглавление проектной документации...
Не так всё однозначно не слайде "Чем придётся заплатить", имхо, ключевой момент всей этой чистой архитектуры. Тк в реальном проекте так и выходит: тут не1 однозначно, там не однозначно, 10 раз не однозначно, и вот мы уже получили винегрет из "слоистой" и чистой архитектуры...
Пол года без БД? Да вы о чем? Нас после этого всех разгонят. Все проекты делаются по принципу "нужно было ещё вчера", если ты через неделю не покажешь работающую админку заказчику -- будешь потом на собеседовании рассказывать про чистую архитектуру и пол года без бд! 🤣🤣🤣 я конечно утрирую, но и вы тут перегнули палку, надо было сценарий лучше прописать ;)
Пример с театром -- сильно надуманный, немного портит впечатление, сразу хочется поспорить :)
А так видео хорошее, спасибо! Есть пара новых моментов о чем подумать :)
Правда лучше смотреть на скорости 1,5х :))))
Один из законов разработки:
Everything in software architecture is a trade-off)
Структура папок и файлов - это не чертежи, это уже реализация.
"Чертежи" приложения - это какие-нибудь UML-схемки, диаграмки. А из них уже более чем понятно что за приложение.
Мысль годная, сравнение - бестолковое.
9:25 осуждаем
Раскройте подробнее?)
@@gradeaification ну надо интересоваться всем, тем более что на фронте целый мир, не легче чем на беке )
@@ahmedrapira7610 слишком он большой стал и стремительный, я тоже перестал успевать и забросил)
У нас не очень много времени потому потратим 30 минут что бы посмотреть на дибильные вопросы результатом которых, о боже, не вероятно, домен является самым важным. РАНЬШЕ думал что самое главное это фреймворк которые раз в год выходит новый
Очень устал от понтов, но на том что базы затлчены современные на крутилки чет не выдержал
Евгену тяжело пришлось роль играть несведущего))
Я услышал много про чистую архитектуру и почти ничего про DDD. Такое чувство, что спикеры пытаются подсунуть чистую архитектуру под видом DDD.
Некорректная связь между ген. планом и структурой каталогов приложения. Вместо этого стоило бы использовать UML диаграммы тогда уж.
Про анемичную модель - не убедил!
Спасибо! Очень интересно! Также понравилась книга Get Your Hands Dirty on Clean Architecture by Tom Hombergs , там немного по другому структура папок сделана, но идеи те-же
Regarding books, the content of Matthias Noback is very good which is going in the right direction to implement Clean Architecture. Also Implementing Domain Driven Design and Growing Object-Oriented Software Guided By Tests.
Ребята, вы говорите что анемичная модель - это плохо, но аргументы в защиту этого утверждения приходится придумывать на ходу. Вы уж простите, но это несерьезно. Если прочитаете это сообщение, можете оставить под ним более емкое обоснование своего тезиса.
Да, пожалуй, аргументы не самые убедительные, но вспомнить всё сразу оказалось довольно трудно. Мы планируем написать об этом подробнее в бложике. Опубликуем ссылку здесь.
Есть подозрение, что написав проект без чистой архитектуры, а с обычной продуманной архитектурой разницы будет ноль, просто программистам скучно. Если бы этот подход был лучше стандартного анемичного например, то он бы уже стал стандартом, как реактивное программирование на 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+ безнес задач. ))))
Спасибо!!!