«Досконалі» архітектурні рішення

Мої вітання!

Я збираю, на мою думку, цікаві архітектурні, і не тільки, рішення (feellikeagrownup.files.wordpress.com/2015/08/leonard.jpg), і хочу поділитись ними з вами, і почути подібні.

Цілі що я переслідую цим топіком: посміятись(не цинічно), можливо натовкнути на думку що не треба так робити, або зрозуміти що я в корінь не правий і треба відкрити півчанській і дивитись телевізор

Почнемо:
1. Давайте створимо клас з глобал константами, а потім не будем ними користуватись а будем хардкодити стрінгі — шоб всім було «легше» міняти їх

2. Слабо типізовані мови то холі грааль для девів — можна ж написати функцію котра один раз верне int якшо все ок, а якшо ерор то map вернем з деталями шо сталось, ну і ше може трошка навернутись з ексепшеном — песня

3. Убер розумний фронтенд — от нашо завжди ходити до бекенда і шось там просити, якшо ми знаєм архітекруту і можна на пряму з фронта постучати на третьопартійний сервіс авторизації, потім піти загрузити медіа на пряму на s3 бакет, а потім з токеном від auth сервісу сказати бекенду шо я вже зарегався вот токен вір мені на слово шо я тебе не напарюю, і вот тобі ссилкі на картінкі які я сам же загрузив в твою інфраструктуру без твоєї участі

4. Давайте проксювати всьо з бази даних на фронт — треба тобі того не треба, палимо половину структури і дані які ніколи фронту не треба(я вже писав як гарно на конфі ЕПАМ так робив)

5. Не риба не мясо база — а давайте візьмем релейшен базу даних і половину задизайним правельно(нормалізуєм), а потім вдруг рішимо шо кльово мати декілька колонок котрі мапи(в даному випадко це PostgreSQL спецефічно, JSON field) в які ми валим нові колонкі без міграцій

6. Давайте юзати орм, але дизайнити базу як будто я ООП класи пишу — en.wikipedia.org/...​tional_impedance_mismatch