Федор Щудло "Эволюция Enterprise-архитектур. От MVC до Clean Architecture"

[@bormokov]

спасибо Федор, на бытовом языке донес идею прос и консов! Респект!

[@dmitrypichugin7449]

Спасибо, интересно было послушать.

[@audiofield2159]

Паттерны CQRS и specification не противоречат, а наоборот прекрасно друг друга дополняют в vertical slise arch. А понимание докладчиком cqrs как разделение на read и write очень поверхностное

[@vasylvdovychenko8437]

Спасибо, было очень интересно.

[@АртемРащепкин-ф4н]

Федор, приветствую! Неожиданно, полезно и приятно было послушать! Спасибо за доклад!

[@arsen1156]

Позновательно, спасибо!

[@SCHCOMM]

Хороший доклад, спасибо!

[@tochytskyi]

Слишком базово. Больше похоже на итро книги, а не выводов с нее. Тем не менее спасибо за историческую последовательность архитектур, которую сложить в одну картину не так тривиально :)

[@dmytroshchotkin2939]

Спасибо за доклад. Хорошие вопросы также были заданы.

[@audiofield2159]

И нет, как раз Мартин не понятно рассказывает какие файлы по каким папочкам раскладывать :)

[@NN-ii2mb]

Вы перепутали высокую связность с высокой зацепленностью)

[@ДенисБосый-ю7р]

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

[@ДенисБосый-ю7р]

Адам Смит(специализация) и первый принцип SOLID этому доказательство

[@dmytroshchotkin2939]

Кстати "эксперимент" весьма занятный.

[@audiofield2159]

Ну и самый престарелый паттерн MVC показан очень упрощенно, я бы даже сказал ошибочно упрощенным

[@AlexanderAbramovNN]

Если у заказчика заказать, он перестанет им быть

[@ИванНикитин-ч7б]

48:48 Если в ентити ни когда не ложить логику, то это уже будет анемичная модель. А анемичная модель - это злостный антипаттерн. Касательно вопроса ложить или не ложить с данными логику, сам дядюшка Боб в другой книжке не про архитектуру "Чистый код" подробнейшим образом разбирает эту тему. Глава 6 "Объекты и структуры данных", Заключение: "Если в некоторой системе нас прежде всего интересует гибкость в добавлении новых типов данных, то в этой части системы предпочтение отдается объектной реализации. В других случаях нам нужна гибкость расширения поведения, и тогда в этой части используются типы данных и процедуры. Хороший программист относится к этой проблеме без предубеждения и выбирает то решение, которое лучше всего подходит для конкретной ситуации." С другой стороны, если код пишет в объект (ентити) и ему для этого нужно проанализировать часть данных этого объекта (то есть по сути быть осведомлённым о смыслах внутренней реализации), то значит этот код должен стать поведением данного объекта, т.е. - превратиться в метод этой ентити. Если же для записи в объект требуется проанализировать другой объект, то такой код должен быть внешней им функцией / чужим методом. Код самоизменения объекта должен принадлежать объекту, код взаимодействия объектов должен быть внешним к этим объектам.

[@SklerozRu]

Слишком громко

[@имяфамилия-э7ы2е]

Из видео уяснил, что микрософт понимает mvc неправильно 17:00 , роберт мартин говорит, что принцип single responsibility principle понимается неправильно 20:40. Вот такая эволюция архитектур.

[@nikitross7466]

Не о чем лекция по правде.