Здравствуйте, graniar, Вы писали:
G>А с другой стороны, ты можешь потратить несколько дней на создание "правильной архитектуры" вместо костыля, а применив на практике, сразу поймешь, что это не то, что нужно, и все труды насмарку. Костыль может быть хорошим инструментом для исследования. Главное вовремя их рефакторить, когда теория более-менее устаканивается.
Дело в том, что вовсе не обязательно "создавать архитектуру" — в большинстве случаев достаточно придерживаться базовых принципов и базовых целей. Например, базовая цель: низкая связность. Она даёт возможность реиспользовать компоненты, из обратного: высокая связность мешает отодрать от решения какой-то компонент для того, чтобы использовать его в другом месте или в ином качестве. Для уменьшения связности существуют уже зарекомендовавшие себя решения — паттерны проектирования. Если ты читал банду четырёх, то знаешь — паттерны проектирования они определили именно так. Ещё базовый принцип: SRP — в дальнейшем позволяет вносить точечные изменения, не затрагивая другие части системы. Например, для изменения отображения отдельного компонента изменение вносится только в код отображения и гарантированно не ломает бизнес-логику.
Пытаясь следовать этим целям и принципам ты автоматически делаешь удобоваримую архитектуру, не особо тратясь на её "изобретение".
Всё сказанное выше — личное мнение, если не указано обратное.