Денис Цветцих. Чистая Архитектура и DDD 10 лет спустя

Поділитися
Вставка
  • Опубліковано 26 вер 2022
  • В 2012 году Дядя Боб опубликовал в своем блоге статью о Чистой Архитектуре. Всего через год ВонВернон опубликовал знаменитую «красную книгу» о DDD. Авторы работали независимо, но разрабатывали одну и ту же тему - как сделать качественный монолит. Сегодня эта тема актуальная и для стартапов, и для средних проектов, и для отдельно взятого микросервиса в микросервисной системе, и для модуля в модульном монолите. Мы посмотрим по каким вопросам авторы Чистой Архитектуры и DDD давали похожие рекомендации, а в чем они расходились. И проверим, актуальны ли эти рекомендации сегодня, ровно 10 лет спустя после своего выпуска, а если найдем чем их можно дополнить и улучшить - сделаем это!
    Презентация: disk.yandex.ru/i/1ZSKE-_4wqkMBQ
    Codefest: codefest.ru
  • Наука та технологія

КОМЕНТАРІ • 20

  • @OStrekalovsky
    @OStrekalovsky Рік тому +31

    По докладу видно несколько раз, что автор очень невнимательно читал книгу Вон Вернона.
    1. Слой портов не означает, что порт должен быть один, например только для БД. В той же книге пример системы, где через них интегрируются несколько сервисов.
    2. Он совсем не понял зачем нужны агрегаты - это границы транзакционной консистентности объектов. Поэтому они не должны быть слишком маленькими, но и не слишком большими (будут проблемы с производительностью, но никакого профита).
    3. Насчёт вколачивания ORM в модель - этого не надо делать, т.к. логику работы модели нужно оставить максимально простую. Там и без ORM будет много сложностей. В добавок, модели могут уходить в разные порты через Anticorruption Layer.
    4. Никто не говорит, что DDD нужно всегда затаскивать в проект. DDD - это инструмент для проектов со сложной богатой бизнес логикой. Автор походу с ними просто не сталкивался, а решил похайпить, что типа использует DDD и всё про него понял. Чтобы такие проекты поддерживать в адекватном состоянии нужно выставить соответствующие рамки, а не делать как привыкли для CRUD админок.
    Ну и вообще автор - такой же консультант с платными курсами, как и те люди, которых он в корысти обвиняет. Помолчал бы лучше, чем гнать на просветителей, которые имеют опыта побольше автора, пусть сейчас и "на пенсии" и лучше бы шел внимательнее читать книги.

    • @Animalfox
      @Animalfox День тому

      Да и книгу Роберта Мартина он не читал тоже.

  • @resolution07
    @resolution07 8 місяців тому +6

    Слушаю и думаю - херь какая-то. Захожу в комментарии, оказывается не один я так думаю)

  • @SbWereWolf
    @SbWereWolf 7 місяців тому

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

  • @ejoys3
    @ejoys3 Місяць тому +1

    Тот случай когда человек максимально далек от темы по которой читает доклад.

  • @PoletaevRoman
    @PoletaevRoman 22 дні тому

    Прикольно он книгу читал. Я вообще про unit of work из красной книги узнал.

  • @ivan42832
    @ivan42832 5 місяців тому

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

  • @artemrusinov3034
    @artemrusinov3034 Рік тому +17

    какой-то бредогенератор. чего хочет сказать сам не знает

  • @egormerkushev
    @egormerkushev Рік тому +2

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

  • @admivang
    @admivang Рік тому

    Реклама курса на юдеми из доклада заинтересовала но качество звука отбило все желание изучать такой курс, даже если контент неплохой

  • @DzhigurdaAnton
    @DzhigurdaAnton Рік тому +2

    Про каскадное удаление, это не в базе потому что бизнес правило.

  • @sergafanasiev7956
    @sergafanasiev7956 7 місяців тому +3

    дизлайк. вообще никак. набор слов. автор не зачот! не осилил! DDD это лучшее что я слышал в разговорах об архитектуре. ValueObject'ы - это про immutable-состояния, Entity - этодля поведения, Агрегаты - для транзакционности и инвариантности. Ограниченные Контексты - это потенциальные микросервисы.

  • @Argon-X
    @Argon-X 8 місяців тому

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

  • @jellyfish6265
    @jellyfish6265 7 місяців тому

    автор быстро погрузился в детали и не особо объяснил разницу в подходах

  • @user-sq3nn5wq3z
    @user-sq3nn5wq3z Рік тому +4

    dislike

  • @evgen-lav
    @evgen-lav Рік тому +1

    Интересно, но не согласен

  • @Animalfox
    @Animalfox День тому

    Господи что за фигня?
    1. Анемичная модель нормально? Смысл рич модели в том, что бы содержать предусмотренное решение в себе, а не хранить раскинутым по разным классам, смысл в том что бы недопустить замусоривание проекта, вдруг другие классы начнут создавать отсутствующие в анемичной модели методы, как тогда их поправить единоразово везде?
    Вы вообще книги читали по этим архитектурам или от себя все выдумали? :(
    2. Аггрегаты это вообще что за нафик, это выглядит как костыль какой то компаннии, когда им потребовалось использовать частный случай но в то же время сам агрегат по факту сущность так, зачем вы разделяете сущности на агрегаты? И то и другое просто сущности, наследованные от других сущностей. Есть сущности и точка.
    После половины презентации автор начал втирать какую то дичь в виде частных случаев с которыми у него не вышло справиться потому что блин он не разбирается в теме... о чем доклад вообще непонятно, ух...
    9 359 просмотров, 229 лайков... хд

  • @oronstil
    @oronstil 4 місяці тому

    Не советую это смотреть