что нужно отделять гуй, usecase, бизнес сущности и т.д.

Потому что, если доступно много программистов, то скорость разработки растёт только до тех пор, пока каждому программисту можно выдать отдельный, с независимой от других реализацией, модуль.

Для этого приучают на учебных проектах разделать проект на модули. Так как правильно разделять произвольный проект — это скорее искусство, то придумали способы как-бы стандартного разбиения (паттерны). В общем случае они не дают правильного разбиения, но если у тебя есть 50 программистов, то любое разбиение лучше, чем его отсутствие.

Игровые движки, физические движки.

Например, работающие под андроидом и айосом с общей кодовой базой?

Например, работающие под андроидом и айосом с общей кодовой базой?

Да, почему вас это удивляет?
Мой движок работает под android, android tv, ios, tvos, linux, osx, windows (в теории можно запустить и на windows phone). Весь код игры написан на c++.

Завтра линус и все-все-все перестанут поддерживать ядро. Ты правда обо всем этом заботишься?

debian https://www.debian.org/ports/

если юзер знает домашний адрес кодера - то нельзя, на втором залипании кнопки - придет домой ночью

чушь какая-то...

ну, захочешь ты поменять светлую тему твоего приложения на тёмную — пол проги переписывать?

потребуется часть данных получать не из БД, а от REST-сервисов — будешь бизнес-логику перелопачивать?

или, к примеру, где-то в источниках данных произошла смена формата даты/времени — будешь программу переписывать?

или какая-то универсальность быть должна? где та грань, когда универсальность кода для тебя перестаёт быть избыточной?

кстати, вот, почитай:

http://i72.narod.ru/humor/revolution.htm

это почему программисты стали с недоверием относиться к «постоянству» технологий доступа к данным, сервисам операционных систем и, вообще, к IT.

юмор, конечно, но суть «постоянства» характеризует

смена формата даты/времени — будешь программу переписывать?

Никто не отменял DRY. Следование этому принципу колоссально влияет на архитектуру! Если увидел повторение, запилил абстракцию. Единственное что стремно, так это то, что нужно все эти места помнить, а если ты пишешь в команде, этого добиться нереально.

Через год после моего увольнения в моё приложение добавили i18n и разные валюты, никакие маньяки меня не искали, чяднт?

50 строк реально понять без архитектуры (для многословных джав и адекватных питонов. для C++ и прочих перлов — 5)

МВК не существует, тебя обманули. Вопрос как делить на модули плохо формализуется. Суть в том чтобы изменения во внешнем апи одного модуля сразу же отваливали зависимые модули, но при этом таких отваливающихся мест было бы как можно меньше. Т.е. разбивка должна быть такой чтобы при изменениях требований как можно реже менялось взаимодействие модулей, но при каждом таком изменении можно было легко оценить последствия.

Наверняка и твой вариант будет наиболее подходящим для некоторых случаев.

это обстоятельства неприодолимой силы

Инструмент и технологии, которые ты будешь использовать в проекте, обсуждаются на начальном этапе разработки. Если там немного не подумать, то ССЗБ и проект не взлетит, денег не будет, а ты получишь по шапке (хорошо если контору не разоришь) за то, что полез на должность главного разработчика не имея соответствующих знаний. Ты не должен тянуть всякую каку в проект, например, с закрытым кодом и поддерживаемую явно разоряющейся фирмой с 1,5 калеками-разработчиками, или те технологии, которые скоро или уже deprecated, если потом у тебя нет желания переделывать всё заново с нуля или заниматься поддержкой заброшенного продукта.

поддерживаемую явно разоряющейся фирмой с 1,5 калеками-разработчиками, или те технологии, которые скоро или уже deprecated

А ты прям знаешь все про все фирмы? И знал, например, что тот же сан разорится, его купит оракл и остановит поддержку соляры? Хорошо хоть джаву не выкинули, но что-то подсказывает мне, что джаву в этот период выбирали все так же, хотя перспективы были не самые ясные.

Стесняюсь спросить, чего там оракл остановил?

Опен солярис же закрылся из-за оракла, насколько я помню.

opensolaris закрылся из-за того, что не представлял интереса.

Поддержку opensolaris свернули, но illumos и дистры на его базе вполне себе развиваются. Закрытая соляра как развивалась, так и продолжает.

самая лучшая на свете архитектура

дзен и поросенок
дом из ничего
волк стоит не знает
как сломать его

Я то тут ни при чем))) Просто близко знаком со всем нашим IT-отделом. В принципе придерживаюсь того же мнения - за деньги можно погрязнуть и переделать полностью. Просто если систему переделывать с нуля - ее некоторое время еще и тестировать необходимо, в конце концов с деньгами оперируют. А если есть отлаженное решение, в котором логика отделена в отдельную сущность - на мой взгляд такой код гораздо легче модернезировать под новые задачи.

Конечно, ты не должен. Это как ходить в душ, не бросать мусор на улице, не пердеть при людях. Ты всё это не должен. Единственное последствие — окружающим неприятно.

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

Так и есть. Не надо добавлять в функцию результат от которой есть архитектура посторонние переменные.

Зачем я должен отделять sql код от бизнес сущности если, исходя из требований, никогда не будет меняться метод сохранения в бд?

Почему я не могу из виджета выполнить Http запрос, зная, что это никак не повлияет на сложность внесения дальнейших изменений.

А вообще, это не архитектурные вопросы. Это микродизайн.

Но это архитектурное решение меняться не будет никогда.

никогда

Если тебя зовут не Ванга и не Нострадамус, это «никогда» уж очень смешно звучит. Тебе может внезапно потребоваться на основе своих наработок сделать программу для другой платформы, сам Андроид может начать эволюционировать, и др.