Здравствуйте. К сожалению я для себя так и не понял два вопроса: 1) Если у наших фич есть какой-то общий кусок кода (например фича: создание сущности и её "детей". И это же создание сущности существует как отдельная фича). Нарушаем DRY? Или делаем условный EntityService куда выносим общий код... и вот уже и хвосты от фич появляются. 1 фича = 1 папка - уже не катит. Или допускается вызывать одну команду из другой? Но опять же фича-папка тут уже не сработает. Разве нет? 2) Косвенно продолжая предыдущий вопрос: если для фичи нужно вытягивать из базы сет данных - инжеким дб-контекст в каждый хендлер? Пишем таки репозитории? Или дёргаем query из command'a? Дисклеймер: я понимаю, что "всё зависит от контекста, от задачи. от сроков..", но хотелось бы получить условные best practice в вакууме, чтобы уже их адаптировать к реальности.
Она пугает ровно до того момента, когда вы приходите на проект с 10 летней историей и слоистой архитектурой и любая новая фича может непредсказуемым образом стрельнуть в ногу в каком-то другом участке системы. Бизнес логика размазана слоями по ряду сервисов, контроллеров, сущностей, репозиториев... И смотря на этот цирк с корнями ты точно понимаешь, что так нельзя. И вот в рамках всего этого бардака становится понятно, что то, что предлагает докладчик - must have для энтерпрайз решений.
Вышел доклад с критикой подхода (я несогласен с критикой), за базовую техническую основу взят доклад Максима. th-cam.com/video/isrl_zJa1GY/w-d-xo.html&ab_channel=DotNetRu
"справа хорошо - слева плохо", Странно такое слышать от опытного программиста, не говоря уже о том что код мы пишем не для менеджмента, им не нужен код им нужны фичи, а нам программистам нужен код им с ним дальше работать в отличие от менеджера, и группировать по фичам не всегда хорошо/можно ведь для менеджера просто их реструктуризировать, а с кодом я бы посмотрел как это получиться. Есть подозрение что докладчик сам редко с кодом работает и всё больше теорией занимается, это как некоторые евангелисты микросервисной архитектуры считают её единственно правильным решением, а какие у ней минусы забывают рассказать.
Вау! Они изобрели Express.js! Реально в докладе нету никакой аргументации против нормальной слоеной архитектуры, просто предлагают использовать подход, характерный для Node.js фреймворков, НО!!! Там это применяется из-за ограничений самого js, а не от хорошей жизни. Я конечно за альтернативные мнения, но когда их аргументируют. В каких ситуациях подход лучше? Какие ограничения других походов помогает обойти? Как ограничения приносит а проект?
Расскажите уже функциональщикам про мидлвары. Валидация, логирование, авторизация, обработка ошибок выносится туда, а сервисы и репы спокойно живут себе в чистом виде. Анемик домен модел не просто так изобрели, почему он его нарушил так и не объснено.
Очень интересный доклад, с интересом посмотрел и прочитал на хабре)
Шикарный доклад. Пробую данный подход в скором времени.
Согласен. Вот она - квалификация разработчиков - преподавателей. :great
Мл
Большое спасибо!
Тут выжимка десятка лет опыта) Спасибо!
Спасибо, Максим. Доклад крутой. Может тоже самое можно попробовать с Цепочкой ответственности?
Здравствуйте. К сожалению я для себя так и не понял два вопроса:
1) Если у наших фич есть какой-то общий кусок кода (например фича: создание сущности и её "детей". И это же создание сущности существует как отдельная фича). Нарушаем DRY? Или делаем условный EntityService куда выносим общий код... и вот уже и хвосты от фич появляются. 1 фича = 1 папка - уже не катит. Или допускается вызывать одну команду из другой? Но опять же фича-папка тут уже не сработает. Разве нет?
2) Косвенно продолжая предыдущий вопрос: если для фичи нужно вытягивать из базы сет данных - инжеким дб-контекст в каждый хендлер? Пишем таки репозитории? Или дёргаем query из command'a?
Дисклеймер: я понимаю, что "всё зависит от контекста, от задачи. от сроков..", но хотелось бы получить условные best practice в вакууме, чтобы уже их адаптировать к реальности.
функциональный пайп с общим интерфейсом каждого обработчика :)
идея красивая и фача папка - ваще зачет )
реализация пугает своей многословностью
Она пугает ровно до того момента, когда вы приходите на проект с 10 летней историей и слоистой архитектурой и любая новая фича может непредсказуемым образом стрельнуть в ногу в каком-то другом участке системы. Бизнес логика размазана слоями по ряду сервисов, контроллеров, сущностей, репозиториев... И смотря на этот цирк с корнями ты точно понимаешь, что так нельзя. И вот в рамках всего этого бардака становится понятно, что то, что предлагает докладчик - must have для энтерпрайз решений.
Вышел доклад с критикой подхода (я несогласен с критикой), за базовую техническую основу взят доклад Максима. th-cam.com/video/isrl_zJa1GY/w-d-xo.html&ab_channel=DotNetRu
"справа хорошо - слева плохо", Странно такое слышать от опытного программиста, не говоря уже о том что код мы пишем не для менеджмента, им не нужен код им нужны фичи, а нам программистам нужен код им с ним дальше работать в отличие от менеджера, и группировать по фичам не всегда хорошо/можно ведь для менеджера просто их реструктуризировать, а с кодом я бы посмотрел как это получиться. Есть подозрение что докладчик сам редко с кодом работает и всё больше теорией занимается, это как некоторые евангелисты микросервисной архитектуры считают её единственно правильным решением, а какие у ней минусы забывают рассказать.
Посмотрел доклад. Спасибо, очень интересно и полезный взгляд.
А репа с примерами не появилась?
по CQRS + .NET Core итак уже есть куча примеров, вот толковый (менее "быстрорастворимый" :) ) github.com/gothinkster/aspnetcore-realworld-example-app
Вау! Они изобрели Express.js!
Реально в докладе нету никакой аргументации против нормальной слоеной архитектуры, просто предлагают использовать подход, характерный для Node.js фреймворков, НО!!! Там это применяется из-за ограничений самого js, а не от хорошей жизни.
Я конечно за альтернативные мнения, но когда их аргументируют. В каких ситуациях подход лучше? Какие ограничения других походов помогает обойти? Как ограничения приносит а проект?
На 5:40 потенциальный Null Reference.
Расскажите уже функциональщикам про мидлвары. Валидация, логирование, авторизация, обработка ошибок выносится туда, а сервисы и репы спокойно живут себе в чистом виде.
Анемик домен модел не просто так изобрели, почему он его нарушил так и не объснено.