Денис Цветцих. Чистая Архитектура и DDD 10 лет спустя
Вставка
- Опубліковано 4 лис 2024
- В 2012 году Дядя Боб опубликовал в своем блоге статью о Чистой Архитектуре. Всего через год ВонВернон опубликовал знаменитую «красную книгу» о DDD. Авторы работали независимо, но разрабатывали одну и ту же тему - как сделать качественный монолит. Сегодня эта тема актуальная и для стартапов, и для средних проектов, и для отдельно взятого микросервиса в микросервисной системе, и для модуля в модульном монолите. Мы посмотрим по каким вопросам авторы Чистой Архитектуры и DDD давали похожие рекомендации, а в чем они расходились. И проверим, актуальны ли эти рекомендации сегодня, ровно 10 лет спустя после своего выпуска, а если найдем чем их можно дополнить и улучшить - сделаем это!
Презентация: disk.yandex.ru...
Codefest: codefest.ru
Прекрасно все описал. Браво.
По докладу видно несколько раз, что автор очень невнимательно читал книгу Вон Вернона.
1. Слой портов не означает, что порт должен быть один, например только для БД. В той же книге пример системы, где через них интегрируются несколько сервисов.
2. Он совсем не понял зачем нужны агрегаты - это границы транзакционной консистентности объектов. Поэтому они не должны быть слишком маленькими, но и не слишком большими (будут проблемы с производительностью, но никакого профита).
3. Насчёт вколачивания ORM в модель - этого не надо делать, т.к. логику работы модели нужно оставить максимально простую. Там и без ORM будет много сложностей. В добавок, модели могут уходить в разные порты через Anticorruption Layer.
4. Никто не говорит, что DDD нужно всегда затаскивать в проект. DDD - это инструмент для проектов со сложной богатой бизнес логикой. Автор походу с ними просто не сталкивался, а решил похайпить, что типа использует DDD и всё про него понял. Чтобы такие проекты поддерживать в адекватном состоянии нужно выставить соответствующие рамки, а не делать как привыкли для CRUD админок.
Ну и вообще автор - такой же консультант с платными курсами, как и те люди, которых он в корысти обвиняет. Помолчал бы лучше, чем гнать на просветителей, которые имеют опыта побольше автора, пусть сейчас и "на пенсии" и лучше бы шел внимательнее читать книги.
Да и книгу Роберта Мартина он не читал тоже.
Денис, согласен. Я тоже последнее время склоняюсь у тому, что подавляющее большинство книг далеки от реальных проблем, и зачастую многие подходы являются контр продуктивными, ну либо применимы с большим количеством оговорок которые разумеется не описаны, да и не могут быть описаны т.к. авторы просто глубоко не осознаю прикладных проблем. для этого нужна постоянная практика минимум на 80% своего времени, а они скорее теоретики на момент написания книг. И конечно же рассмотренные книги очень полезны, но есть нюансы. И при конкретной разработки будут постоянные мучения как правильно сделать следуя выбранной архитектуре.
Вообще я бы сказал, что крайне мало информации где действительно глубоко разобран подход именно к прикладному применению теории. Но это и логично, т.к. кто действительно разбирается плохо умеет об этом рассказать, а уж тем более написать популярную книгу, плюс все быстро меняется.
Слушаю и думаю - херь какая-то. Захожу в комментарии, оказывается не один я так думаю)
Автору спасибо за лекцию, создалось впечатление, что больше хотелось высказать претензии, чем конструктивно осмыслить.
Главная мысль - что не надо тащить в проект всё что знаешь - конечно верная, во всём надо знать меру, всему своё место и время.
В остальном не могу согласиться. DDD навсегда, если нет конкретных указаний значит это место для вашего творчества, значит тут вы делаете на ваш вкус как вам понятней и ближе.
DDD это рекомендации, а не инструкция.
Тот случай когда человек максимально далек от темы по которой читает доклад.
какой-то бредогенератор. чего хочет сказать сам не знает
Прикольно он книгу читал. Я вообще про unit of work из красной книги узнал.
дизлайк. вообще никак. набор слов. автор не зачот! не осилил! DDD это лучшее что я слышал в разговорах об архитектуре. ValueObject'ы - это про immutable-состояния, Entity - этодля поведения, Агрегаты - для транзакционности и инвариантности. Ограниченные Контексты - это потенциальные микросервисы.
В финале странноватый наезд на абстрактного архитектора за «вкусовщину». Кажется, что как раз вкусовщиной является безосновательное неприятие некоторых описанных практик, так как в описанном новом проекте а) лектор не в курсе решаемых задач б) нет ещё никаких проблем. Но раз архитектор не лектор, а другой человек, то это его зона ответственности и такая «голая» критика выбора техник есть не критика техник, а критика специалиста их выбравшего, что вообще уже попахивает личной неприязнью.
Реклама курса на юдеми из доклада заинтересовала но качество звука отбило все желание изучать такой курс, даже если контент неплохой
В конце когда услышал спич, что хранимые процедуры и триггеры - это норм решение и лучше, чем агрегат, я окончательно понял, что чел несёт дичь и не понимает ради чего всё это придумывалось. В докладе в основном только критика и если выбросить всё, что он считает лишним, то останется огрызок архитектуры, который приведёт к очередному пиз***у в кодовой базе если проект разрастётся. Критикуешь - предлагай, покажи своё цельное видение архитектуры.
Про каскадное удаление, это не в базе потому что бизнес правило.
Да как вы все меня задрали... пол года архитектуру меняю меняю, лет 10 назад бы уже все написал не парясь, не хайлод и покую, а станет хайлодом, найму таких семенаристов и сами все перепишут мне. Все задрали пишу монилит на mvc!
автор быстро погрузился в детали и не особо объяснил разницу в подходах
Господи что за фигня?
1. Анемичная модель нормально? Смысл рич модели в том, что бы содержать предусмотренное решение в себе, а не хранить раскинутым по разным классам, смысл в том что бы недопустить замусоривание проекта, вдруг другие классы начнут создавать отсутствующие в анемичной модели методы, как тогда их поправить единоразово везде?
Вы вообще книги читали по этим архитектурам или от себя все выдумали? :(
2. Аггрегаты это вообще что за нафик, это выглядит как костыль какой то компаннии, когда им потребовалось использовать частный случай но в то же время сам агрегат по факту сущность так, зачем вы разделяете сущности на агрегаты? И то и другое просто сущности, наследованные от других сущностей. Есть сущности и точка.
После половины презентации автор начал втирать какую то дичь в виде частных случаев с которыми у него не вышло справиться потому что блин он не разбирается в теме... о чем доклад вообще непонятно, ух...
9 359 просмотров, 229 лайков... хд
Не согласен. Чувствуется что человек книгу то не читал.
Кто нибудь видел код, написанный по всей этой шляпе? А я видел и дебажил. Пожалуйстатне пишите эту херню в продакшен коде. Пишите классические mvc, mvp. Все остальное это больные фантазии престарелых шизофреников.
dislike
Интересно, но не согласен
Не советую это смотреть