Чистая архитектура и Domain-Driven Design
Vložit
- čas přidán 23. 03. 2021
- Спикеры:
Сергей Бухаров - Senior Developer Consultant в ThoughtWorks.
Евгений Лукьянов - ex-Yandex.Money, ex-Behavox (UK).
Ссылки:
Презентация: 1drv.ms/b/s!AlCXLk9BEsfKoOA5L...
Репозиторий: github.com/stringconcat/ddd_p...
Сайт stringconcat.com/ru/ и канал t.me/stringconcat
Рассмотрим следующие вопросы:
- Что такое чистая архитектура
- Как она появилась
- Какие проблемы она решает
- Основные приципы чистой архитектуры
- SOLID, метрики, common reuse, etc, кратко
- Что даёт такой подход?
- Как чистая архитектура поддерживает DDD.
Все это с примерами и опорой на код. Длительность ~2 часа.
Внимание! Компания JetBrains поддерживает наше сообщество и у нас есть пара промокодов на годовую лицензию для любой их IDE. Отдадим самым активным участникам. Готовьте ваши вопросы.
Чем дольше смотришь этот ролик, тем чаще вспоминаешь, как он кинотеатр просто театром называл в начале.
Спасибо! Очень интересно и ясно подали идею! 👍
Огромное спасибо! Подача - огонь.
Интересное обобщение, но не на все случаи жизни)
На 1:35:55 запросы в базу в цикле делаются. Невероятно чистый код! Превосходная производительность! Браво, пишите ёще!
Спасибо!
На 11:45 заслуженный лайк за отличное сравнение. Мне очень понравилось, о многом задумался.
Шикарная подача
В докладе говорится и о чистой архитектуре, и о DDD, и о модульном монолите, и о распиливании на микросервисы. В результате и обо всем сразу, и ни о чем конкретно. Лучше было взять одну тему, но рассказать ее подробно.
Не прозвучал главный тезис, описывающий взаимоотношения чистой архитектуры и DDD: чистая архитектура про то, как сделать отдельно взятый баундед контекст, DDD - как большую систему разделить на эти контексты и настроить взаимодействие между ними.
Про чистую архитектуру слишком слабо, показанный игрушечный пример не дает ответов на вопросы, которые возникают в реальных проектах:
- куда девать логику, которая не запихивается в один агрегат? (например, среди всех entities у одной установить IsDefault, а у всех остальных сбросить)
- как переиспользовать между юскейсами дублирующуюся логику
- как лучше реализовать юскейсы, один класс на каждый юскейс, или сервис, в котором реализованы все юскейсы для агрегата
- контроллеры, обязательно ли их выделять в отдельный слой
- в показанном примере юскейсы (RemoveMealFromCartUseCase) находятся в одном слое с интерфейсами инфраструктуры (CartExtractor), этот косяк есть как в книге дяди Боба, так и во всех реализациях чистой архитектуры, которые я видел. Практичнее выносить их в отдельный компонент, но тогда ломается правило зависимостей, согласно которому наружный слой может использовать любые внутренние, но контролеры не должны ходить в инфраструктуру в обход юскейсов.
Прозвучал тезис, что в случае с чистой архитектурой нужно создавать больше классов, чем в какой-то другой (видимо слоистая имелась ввиду). Но не показано примера, на котором это видно.
Ну и зачем были нужны маркетинговые враки типа "полгода работы без базы", "по щелчку пальцев с десктопа на веб" я вообще не понимаю, лучше бы закончили пораньше, а не развозили болтовню на 2 часа.
Да, наш пример относительно игрушечный, но боевой код с прода мы показать не можем. Это обзорная лекция и все подводные камни за два часа разобрать просто нереально.
О взаимоотношении чистой архитектуры и DDD мы говорим на 40:21. ЧА - для выделения модулей, в том числе отделение техники от бизнеса, а также техники между собой, DDD - добавляет модульность с точки зрения бизнеса при помощи ограниченных контекстов.
Всё что мы рассказываем взято исключительно из личного опыта и практики коллег. Отчасти мы показываем это на нашем примере, но похожий пример про базу данных можно увидеть в книге Р. Мартина «Чистая Архитектура» - часть V, глава 17. Fitnesse.
работали вместе с Сергеем в РТЛабсе)
Офигенные ребята, очень бодро и весело рассказывают! Но когда дело дошло до кода - началась каша, я окончательно запутался, где что и кем используется, заплакал и ушел)
шикарная подача!!
вы можете обрезать начало где идут понты?
Дак кажется тут только понты и есть все видео из них
Я перемотал понты
Видео без понтов - безпонтовое
😂😂😂 +1
ахаха беспонтовое@@Deletedeletedelete
Фух не так просто выиграть Евгения в гляделки, но я это сделал
(минуте к тридцатой)
Спасибо за публикацию спитча, было интересно, но я тоже не успел осознать весь кода из вашего примера. Понимаю что сжатое время, но может один метод новый в application модуле написать и это как-то улучшит понимание. Исходный код можно посмотреть только оплатив курс? :)
папка в проекте это не ген план. ген план это диаграмvа use case, из которой например и будет понятно назначение приложения :)
Спасибо! Очень интересно! Также понравилась книга 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.
Евгену тяжело пришлось роль играть несведущего))
47:26 - парень Евгений говорит, что ничего страшного нет, чтобы расширить интерфейс ради 1 объекта, хотя другим оно не надо --> ничего страшного. Как ничего страшного? А внести изменения в конструкторы во всех местах? Или в сигнатуры методов. Что-то непонятно.
Где вы джима керри нашли?
Опа, Бухаров, а нам не скинул видос -_-
И вот например надо с фронта указать какой entity graph использовать чтобы вытянуть сущность, не писать же на каждый вариант find по методу ? У нас сущность мапится в дто, и лези поля в дто будут нулами, что удобно, не режется производительность лишний раз. Но это уже какая-то не очень чистая архитектура получается, когда приходится графы так передавать. И таких моментов много, что нивелирует чистоту впринципе
для этих сценариев просто идеально подходит GraphQL (использовали на проде и это было шикарно)
Очень странно сравнивать структуру проекта и строительный чертеж. Я думаю, если бы посмотрели на файловую структуру проекта, вы бы тоже ничего не поняли. Правильно в данном случае было бы смотреть на архитектурные документы и диаграммы. А вот там бы как раз все было бы понятно.
Понятно, о чем идет речь, но аналогия под сильным воздействием литературной гиперболы.
когда показывали класс Menu, упомянули поле version, которое используется для оптимистической блокировки. И тут у меня сразу дисонанс, потому что это поле явно не относится бизнес-домену Menu, а относится к решению проблемы конкуретности в бд. Это в целом норм, или не норм? Или приходится идти на такого рода уступки? Если это действительно проблема, то можно ли ее решить?
Иногда технические вещи (гуиды, версии) протекают в домен. Как по мне - не стоит с этим перебарщивать, но и избавляться во что бы то ни стало не надо, особенно если это некий единный подход в проекте.
Объясните, пожалуйста, как блюдо добавляется в меню?
Спасибо!!!
9:25 осуждаем
Раскройте подробнее?)
@@gradeaification ну надо интересоваться всем, тем более что на фронте целый мир, не легче чем на беке )
@@ahmedrapira7610 слишком он большой стал и стремительный, я тоже перестал успевать и забросил)
Очень устал от понтов, но на том что базы затлчены современные на крутилки чет не выдержал
Про анемичную модель - не убедил!
Звук это инфраструктурный слой?
ЕРЕТИК
Структура папок и файлов - это не чертежи, это уже реализация.
"Чертежи" приложения - это какие-нибудь UML-схемки, диаграмки. А из них уже более чем понятно что за приложение.
Мысль годная, сравнение - бестолковое.
У нас не очень много времени потому потратим 30 минут что бы посмотреть на дибильные вопросы результатом которых, о боже, не вероятно, домен является самым важным. РАНЬШЕ думал что самое главное это фреймворк которые раз в год выходит новый
Не так всё однозначно не слайде "Чем придётся заплатить", имхо, ключевой момент всей этой чистой архитектуры. Тк в реальном проекте так и выходит: тут не1 однозначно, там не однозначно, 10 раз не однозначно, и вот мы уже получили винегрет из "слоистой" и чистой архитектуры...
Пол года без БД? Да вы о чем? Нас после этого всех разгонят. Все проекты делаются по принципу "нужно было ещё вчера", если ты через неделю не покажешь работающую админку заказчику -- будешь потом на собеседовании рассказывать про чистую архитектуру и пол года без бд! 🤣🤣🤣 я конечно утрирую, но и вы тут перегнули палку, надо было сценарий лучше прописать ;)
Пример с театром -- сильно надуманный, немного портит впечатление, сразу хочется поспорить :)
А так видео хорошее, спасибо! Есть пара новых моментов о чем подумать :)
Правда лучше смотреть на скорости 1,5х :))))
Один из законов разработки:
Everything in software architecture is a trade-off)
Сравнение скрина фреймворка с чертежами, дикая дичь. Вы бы фото кирпича показали ещё... Или оглавление проектной документации...
Видно что Сергей Бухаров умеет донести инфу слушателю , приятно его слушать
Я услышал много про чистую архитектуру и почти ничего про DDD. Такое чувство, что спикеры пытаются подсунуть чистую архитектуру под видом DDD.
Ребята, вы говорите что анемичная модель - это плохо, но аргументы в защиту этого утверждения приходится придумывать на ходу. Вы уж простите, но это несерьезно. Если прочитаете это сообщение, можете оставить под ним более емкое обоснование своего тезиса.
Да, пожалуй, аргументы не самые убедительные, но вспомнить всё сразу оказалось довольно трудно. Мы планируем написать об этом подробнее в бложике. Опубликуем ссылку здесь.
Некорректная связь между ген. планом и структурой каталогов приложения. Вместо этого стоило бы использовать UML диаграммы тогда уж.
Есть подозрение, что написав проект без чистой архитектуры, а с обычной продуманной архитектурой разницы будет ноль, просто программистам скучно. Если бы этот подход был лучше стандартного анемичного например, то он бы уже стал стандартом, как реактивное программирование на 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+ безнес задач. ))))