Comments 5
вступает в силу второй закон архитектуры: любое решение является компромиссом, у которого есть сильные и слабые стороны
А какой первый? А лучше огласите весь список, пожалуйста
Первый: любое решение в архитектуре - это компромисс.
С плюсами всегда в наборе получаешь минусы. Нужно понять, какие архитектурно-значимые функциональные требования критичны и какие нефункциональные требования порождают. Далее - ранжирование по критичности (требования могут быть диаметрально противоположными: хочу чтобы система выдерживала 1млн запросов/сек - high throughput и задержка ответа составляла не более 10мс - low latency) и подбор паттерна, который лучше подходит для выполнения критичных требований.
Фиксация минусов и проработка, чем их нивелировать или какие риски нужно принять (иногда достаточно просто о них знать, так как они могут проявляться в каком-то изменившемся контексте или новых требованиях).
@komgbu прав, а вот я в статье слегка напутал
В книжке выводится всего два закона архитектуры.
Первый закон:
Everything in software architecture is a trade-off.
Любое решение является компромиссом (о чём @komgbu чётко расписал).
Второй закон:
Why is more important than how.
Вопрос "почему" является важнее вопроса "как". Для меня это стало тоже очень ценным подспорьем в спорах с коллегами, которые слишком рано уходят в детали имплементации, не рассматривая картину целиком.
Ещё бывают ситуации, что архитектуру детально прописываешь, согласовываешь, создаёшь RFC, рисуешь диаграммы разного уровня детализации, составляешь секцию FAQ, а потом приходит человек и начинает спрашивать вопросы которые в явном виде уже описаны в документе. Просто ему/ей лень читать.?
Типичные ошибки архитектора, или Как перестать бояться и полюбить RFC