Максим Аршинов - Быстрорастворимое проектирование
HTML-код
- Опубликовано: 24 авг 2024
- Ближайшая конференция - DotNext 2024, 10 - 11 сентября, Москва + online
Подробности и билеты: jrg.su/x2GKnA
- -
Люди учатся архитектуре по старым книжкам, которые писались для Java. Книжки хорошие, но дают решение задач того времени инструментами того времени. Время поменялось, C# уже больше похож на лайтовую Scala, чем Java, а новых хороших книжек мало.
В этом докладе Максим расскажет о критериях хорошего кода и плохого кода, как и чем мерить. Сделает обзор типовых задач и подходов, разберет плюсы и минусы. В конце даст рекомендации и best practices по проектированию web-приложений.
![Eminem - Somebody Save Me (feat. Jelly Roll) [Official Music Video]](http://i.ytimg.com/vi/Vwa0HenQMi4/mqdefault.jpg)
Очень интересный доклад, с интересом посмотрел и прочитал на хабре)
Шикарный доклад. Пробую данный подход в скором времени.
Согласен. Вот она - квалификация разработчиков - преподавателей. :great
Мл
Тут выжимка десятка лет опыта) Спасибо!
Большое спасибо!
Здравствуйте. К сожалению я для себя так и не понял два вопроса:
1) Если у наших фич есть какой-то общий кусок кода (например фича: создание сущности и её "детей". И это же создание сущности существует как отдельная фича). Нарушаем DRY? Или делаем условный EntityService куда выносим общий код... и вот уже и хвосты от фич появляются. 1 фича = 1 папка - уже не катит. Или допускается вызывать одну команду из другой? Но опять же фича-папка тут уже не сработает. Разве нет?
2) Косвенно продолжая предыдущий вопрос: если для фичи нужно вытягивать из базы сет данных - инжеким дб-контекст в каждый хендлер? Пишем таки репозитории? Или дёргаем query из command'a?
Дисклеймер: я понимаю, что "всё зависит от контекста, от задачи. от сроков..", но хотелось бы получить условные best practice в вакууме, чтобы уже их адаптировать к реальности.
функциональный пайп с общим интерфейсом каждого обработчика :)
идея красивая и фача папка - ваще зачет )
реализация пугает своей многословностью
Она пугает ровно до того момента, когда вы приходите на проект с 10 летней историей и слоистой архитектурой и любая новая фича может непредсказуемым образом стрельнуть в ногу в каком-то другом участке системы. Бизнес логика размазана слоями по ряду сервисов, контроллеров, сущностей, репозиториев... И смотря на этот цирк с корнями ты точно понимаешь, что так нельзя. И вот в рамках всего этого бардака становится понятно, что то, что предлагает докладчик - must have для энтерпрайз решений.
Спасибо, Максим. Доклад крутой. Может тоже самое можно попробовать с Цепочкой ответственности?
Вышел доклад с критикой подхода (я несогласен с критикой), за базовую техническую основу взят доклад Максима. ruclips.net/video/isrl_zJa1GY/видео.html&ab_channel=DotNetRu
"справа хорошо - слева плохо", Странно такое слышать от опытного программиста, не говоря уже о том что код мы пишем не для менеджмента, им не нужен код им нужны фичи, а нам программистам нужен код им с ним дальше работать в отличие от менеджера, и группировать по фичам не всегда хорошо/можно ведь для менеджера просто их реструктуризировать, а с кодом я бы посмотрел как это получиться. Есть подозрение что докладчик сам редко с кодом работает и всё больше теорией занимается, это как некоторые евангелисты микросервисной архитектуры считают её единственно правильным решением, а какие у ней минусы забывают рассказать.
Посмотрел доклад. Спасибо, очень интересно и полезный взгляд.
Вау! Они изобрели Express.js!
Реально в докладе нету никакой аргументации против нормальной слоеной архитектуры, просто предлагают использовать подход, характерный для Node.js фреймворков, НО!!! Там это применяется из-за ограничений самого js, а не от хорошей жизни.
Я конечно за альтернативные мнения, но когда их аргументируют. В каких ситуациях подход лучше? Какие ограничения других походов помогает обойти? Как ограничения приносит а проект?
А репа с примерами не появилась?
по CQRS + .NET Core итак уже есть куча примеров, вот толковый (менее "быстрорастворимый" :) ) github.com/gothinkster/aspnetcore-realworld-example-app
Расскажите уже функциональщикам про мидлвары. Валидация, логирование, авторизация, обработка ошибок выносится туда, а сервисы и репы спокойно живут себе в чистом виде.
Анемик домен модел не просто так изобрели, почему он его нарушил так и не объснено.
На 5:40 потенциальный Null Reference.