ฝัง
- เผยแพร่เมื่อ 22 ต.ค. 2024
- Слайды: bit.ly/2ZBa9X1
Расскажу историю развития архитектур enterprise-приложений, начиная от MVC 70-х годов и до Clean Architecture.
Рассматривая подходы последовательно, гораздо легче понять логику развития, что упрощает понимание каждой отдельно взятой архитектуры.
Также обговорим различия между архитектурами "Ports and Adapters", "Onion Architecture" и "Clean Architecture", которые многие считают одним и тем же.
![TEEDEE TADA - DIAMOND NARAKORN X LEGO LYKN [Special Dance Performance]](http://i.ytimg.com/vi/QgtZedFeumA/mqdefault.jpg)
![Просто о сложном - Domain Driven Design [ru] / Дмитрий Науменко](/img/n.gif)
спасибо Федор, на бытовом языке донес идею прос и консов! Респект!
Спасибо, интересно было послушать.
Федор, приветствую! Неожиданно, полезно и приятно было послушать! Спасибо за доклад!
Паттерны CQRS и specification не противоречат, а наоборот прекрасно друг друга дополняют в vertical slise arch. А понимание докладчиком cqrs как разделение на read и write очень поверхностное
Спасибо, было очень интересно.
Позновательно, спасибо!
Хороший доклад, спасибо!
Слишком базово. Больше похоже на итро книги, а не выводов с нее. Тем не менее спасибо за историческую последовательность архитектур, которую сложить в одну картину не так тривиально :)
Спасибо за доклад. Хорошие вопросы также были заданы.
Вы перепутали высокую связность с высокой зацепленностью)
И нет, как раз Мартин не понятно рассказывает какие файлы по каким папочкам раскладывать :)
По поводу сложности системы надо бы уточнить: победить не та система, которая является наиболее сложной, а та система, которая является наиболее сложной в рамках узкоспециализированной задачи. К примеру, человек может проиграть в шахматы боту, хотя человек является относительно более сложной системой
Адам Смит(специализация) и первый принцип SOLID этому доказательство
Кстати "эксперимент" весьма занятный.
Ну и самый престарелый паттерн MVC показан очень упрощенно, я бы даже сказал ошибочно упрощенным
Если у заказчика заказать, он перестанет им быть
48:48 Если в ентити ни когда не ложить логику, то это уже будет анемичная модель. А анемичная модель - это злостный антипаттерн. Касательно вопроса ложить или не ложить с данными логику, сам дядюшка Боб в другой книжке не про архитектуру "Чистый код" подробнейшим образом разбирает эту тему. Глава 6 "Объекты и структуры данных", Заключение: "Если в некоторой системе нас прежде всего интересует гибкость в добавлении новых типов данных, то в этой части системы предпочтение отдается объектной реализации. В других случаях нам нужна гибкость расширения поведения, и тогда в этой части используются типы данных и процедуры. Хороший программист относится к этой проблеме без предубеждения и выбирает то решение, которое лучше всего подходит для конкретной ситуации."
С другой стороны, если код пишет в объект (ентити) и ему для этого нужно проанализировать часть данных этого объекта (то есть по сути быть осведомлённым о смыслах внутренней реализации), то значит этот код должен стать поведением данного объекта, т.е. - превратиться в метод этой ентити. Если же для записи в объект требуется проанализировать другой объект, то такой код должен быть внешней им функцией / чужим методом.
Код самоизменения объекта должен принадлежать объекту, код взаимодействия объектов должен быть внешним к этим объектам.
Слишком громко
Из видео уяснил, что микрософт понимает mvc неправильно 17:00 , роберт мартин говорит, что принцип single responsibility principle понимается неправильно 20:40. Вот такая эволюция архитектур.
Не о чем лекция по правде.