хорошо спроектированная система, как ты предлаегаешь, даже если она будет спроектирована по каким то иным принципам при этом удовлетворяющим целям всегда будет давать такой ответ за ограниченное время. проблема в том, что это просто не возможно. ты предлагеашь подход с проектированием на перед всего до мелочей(через интерфейсы и соответственно контракты) это не только "надо подумать" это надо еще сделать и что бы оно работало быстро и что бы... в общем этого что бы много бывает. особенно начнутся проблемы над компксными данными, вдля которых сложно выделить хорошие абстракции. собственно абстракции и то, что они прямо завязаны на мышление разработчика это самое слабое место этой теории. твое и мое виденьего одного и того же объекта сильно разняться, мы оба выделим в какой то момент разные абстракции, они обе будут для нас хороши, но ужасны для другого. мне сложно привести сейчас какой то простой пример, но уверен, что он существует. мы как минимум можем допустить его существование и тогда стройная взаимозаменяемая система с использованием всех благородных принципев резко оказывается довольно сложно управляемой машиной. начинают течь абстракции в том смысле что происходит логический взрыв роста, это не избежно я бы даже сказал основываясь на том, что с течением времени любая программа которая претендует на моделирование действительности сталкивается с тем, что реальность слишком сложна, для упоковывания в байтики на диске на данный момент. это в свою очередь приводит к двойной работе - пока я рефакторю то, что наколякал Вася(я на самом деле врят ли буду рефактироить а как нибудь поверх впилю), ты в свою очередь будешь выделять абстракции.
что то, что это на мой взгляд одно и тоже, толкьо ментальных сил ты потратил больше, а я меньше

> ты предлагеашь подход с проектированием на перед всего до мелочей

Нет, ты меня не так понял. Я расставил акценты — что действительно важно для построения качественных абстракций. И это внезапно не знания паттернов, ни DI, ни еще какая нить хрень, а знания целей. Я не предлагаю проектировать все наперед, скорее всего это все равно будет ошибкой. Я предлагаю трекать в процессе дизайна другие вещи.

наверное не понимаю, что подразумевается под словом "цель". на мой взгляд "цель" это то, куда стремится проект и/или его часть. наприимер у сервиса UserService вероятно цель в обработке запросов связанных с пользователями. мы закладываем эти цели исходя из наших весьма и весьма субьективных представлений о некой модели. если мы говорим именно о моделировании. в моем понимании UserService не обрабатывает никаких запросов, это структура данных описывающая набор действий над классом User, то есть над видом. в моем понимании на класс надо смотреть как на некий вид данных сгруппированных по некотороемому признаку. например мы выделим класс User, то есть сущность обладающая, но не ограниченная, пользователем системы. в таком случае сам User это не более чем дто, набор признаков. все действия над пользователем выполняются соответствующим сервисом и это выглядит стройно и логично.
если мы посмотрим с этой стороны на архитектуру приложения, мы увидем, что для нас легко из данных извлечь виды и легко определить операции над этими данными

вообще все очень условно у нас в индустрии. и по моему опять же опыту - это хорошо

Прочитал половину книги кстати уже.  Много вещей на уровне коммон сенс, но столько же и вещей с которыми лично я оч не согласен. А какие то вещи вызывают у меня и вовсе приступы. Например та часть про юнит тесты и фейк объекты.

Мне кажется что вы, господа, просрали вечер пятницы

Заходят однажды социолог, искусствовед и инженер в бар. Кто из них вероятнее всего террорист? По мнению двух британских исследователей Диего Гамбетты и Стефена Хертога, это инженер. В относительно недавней книге они показывают, что вероятность для инженера стать радикальным (исламским) террористом – в 3-4 раза выше, чем у выпускников по другим специальностям. И разгадка тут не в том, что инженеры просто нужнее для террористов, потому что умеют конструировать вещи. Основываясь на статистике, авторы говорят, что разгадка - в особом «инженерном мировоззрении». Это мировоззрение имеет одну решительную черту, которая, вероятно, сближает инженеров и террористов: стремление к когнитивному замыканию (closure), или, иначе говоря, предпочтение порядка и нелюбовь к двойственности и неоднозначности. Та же черта характерна и для членов организаций с радикальными правыми взглядами, пишут авторы, и инженеров среди них тоже довольно много.

Данные выводы авторов до сих пор будоражат исследователей инженерного образования. И заставляют некоторых из них менять набор курсов для новых инженеров, делая их более ориентированными на плюрализм и открытость. Другие же полагают, что «инженерное мировоззрение» вообще мало о чем нам говорит. Во-первых, инженеры – это ну очень разные типы специальностей, не говоря уже о должностях. Во-вторых, исследователи образования говорят, что мировоззрение студентов-инженеров формируется не столько в аудиториях с формулами и графиками, сколько в общении со своими сверстниками.

Лично я согласен с критикой некоторого единого инженерного мировоззрения. К примеру, беглый анализ образования террористов-революционеров в конце XIX в Российской империи показывает, что там были и люди с техническим образованием, и с гуманитарным. Но в то же время я согласен и с тем, что в современных разработках и внедрении технологий нужно как из аксиомы исходить из разных перспектив, разных интересов, разных представлений. И об этом – уже в защиту инженеров – есть чудесная книга Гуру Мадхавана «Думай как инженер». Вроде бы тоже о мировоззрении, но совсем иначе.