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