Здравствуйте, Nikita Lyapin, Вы писали:

NL>1. Тестов либо нет, либо они делаются QA ручками без всяких CI CD. Либо они интеграционные и медленные. И доля интеграционных тестов — большинство. Все это работает и так делать можно. Но если проект у вас не крупный. И даже не средний. Если тесты выполняются руками, то в крупном проекте регрес будет проходить за неделю. Правите в одном месте — опять полный регрес. Если интеграционные тесты — в крупном проекте их тысячи. Должны быть быстрыми для комфортной разработки.
NL>2. Обьем кода от ООП (ОРМ и обвесов) не растет линейно. Т.е. да, вы в начале добавляете 200 строк кода. Но по мере роста вы не добавляете по 200 строк на каждое бизнес-правило. Наоборот. Дополнительный оверхед достигается за счет мапинга, сервисов и репозиториев. Далее вы уже используете готовую инфраструктуру. Отсюда вывод — для маленького проекта не имеет смысла. Дла большого — имеет.
NL>3. Все такпи статичекие переменные — это как раз признак процедурности. Ну или в любом случае затрудненной сопровождаемости кода. Командная работа, поять же сложный и комплексный домен, который невозомжно уместить в голове — все это сразу мимо. И опять — для маленького проекта все окей.
NL>Итого, стиль который вы описали отлично подходит для небольшого по обьему проекта. Со сложным — будут проблемы. Единственное, что тут нужно учесть — это микросервисы. С их приходом каждый конкретный микросервис в целом простой. И там вполне можно так писать. И я бы даже сказал, что иногда нужно так и только так.
NL>Вот такая у меня позиция.
Давайте так — покажите код, который реализует вот это простое бизнес-правило "сотруднику предоставляется самый дешёвый автомобиль среди тех, которые ему можно использовать".
С тестами.
Может быть, действительно, linq будет плохим ответом на подобную задачу.