Часть 1. Об архитектуре и фреймворках
Для начала в очередной раз внесем ясность в вопрос, что же такое архитектура. Сколько десятилетий термин в ходу, и в него постоянно вносят ясность - без особого толка. Однако, коль скоро мы собираемся о ней говорить, это совершенно необходимо сделать в очередной раз. Иначе будет просто не понятно, о чем речь.
Архитектура* - это набор формальных и неформальных *правил*, руководствуясь которыми люди проектируют систему.
Результат проектирования - это как правило некоторая высокоуровневая структура системы, которую тут же снова называют словом "архитектура" (ну вот мало у нас слов, и те все иностранные), а потом начинают ломать голову, чем же это отличается от "дизайна", и пр. И накидывать при этом кучу умняка. Мы не будем. Вместо этого:
- Мы будем стараться использовать для обозначения нашего понимания термин "Common Design Principles".
- Постараемся разобраться в определении, и как оно соотносится с фреймворками и структурами. Увидете, как только вы начнете думать об архитектуре как о правилах много встанет на свои места.
Ну вот как это, правила? - спросите вы. Ну вот у меня в системе, например, MySQL, я пишу сервер на PHP с фреймворком Laravel. Вот, могу слои нарисовать, какие у меня есть. Где здесь правила? - скажете вы. Да здесь их куча. И я вам сейчас их покажу.
Во-первых, подразумевается, что все меняющиеся данные (или по карйней мере большинство) должны храниться в MySQL. Как, у вас нет такого правила? Вы можете легко заменить MySQL на PostgreSQL? Значит, правило более ограничивающее - данные должны хранится в реляционной форме, и плюс к этому вы не должны полагаться на уникальные возможности конкретной БД в работе с ними.
Во-вторых, "с фреймворком Laravel" означает, что вы не должны работать с табличками в своей базе напрямую, подразумевается, что вы должны делать это через ORM. И Laravel дает вам кучу своих правил, как это делать.
Эти правила очень сильно ограничивают вам множество вариантов, как может выглядеть структура вашего приложения, но, при этом, не ограничивают вас в в том, что будет делать ваше приложение (т.е. "функциональные требования"). И, таким образом, упрощают вам проектирование системы:
- Искать решение в меньшем множестве вариантов - проще и быстрее, естественно, при наличии навыка работы с данными правилами.
- Много людей могут проектировать в рамках этих правил, и более-менее легко понимать решения друг друга.
Вам не придется ломать голову о решении множества мелких технических проблем - пока вы остаетесь в рамках правил, это все делается за вас.
Это все замечательно, но, конечно, не бесплатно. Правила могут ограничивать производительность, что может стать проблемой. Ну и в конце концов, правила соблюдают люди. А им соблюдать правила не всегда легко, и далеко не в каждом случае их соблюдение приносит пользу. Иногда правила настолько сложны, что инженеры их не понимают. А как можно соблюдать то, что не понимаешь?
Вообще, чтобы архитектура была архитектурой, а не фантазией, легко опровергаемой заглядыванием в код, необходимо всегда помнить, что эти правила выполняют люди. Поэтому, если вы хотите чтобы люди их соблюдали:
- Про правила проектирования должны все в команде знать. Нет ни малейшего шанса следовать неизвестным правилам. То есть, если у вас в ящике стола лежит секретная диаграмма, про которую никто кроме вас не знает - это не архитектура. Что бы там не было написано.
- Все должны их понимать и помнить. Люди в принципе не в состоянии следовать тому, что они не поняли. То есть, правила должны быть очень простыми, и их не должно быть много. Это значит, что если ваши правила хоть чуть-чуть напоминают правила игры в "драконий покер" - они являются архитектурой только в вашем воображении, все все равно будут делать по другому.
- Соблюдение правил не должно сильно усложнять жизнь. Люди, надо отметить, и так-то не сильно любят соблюдать правила. Надо напоминать, как они поступают с правилами, требующими для соблюдения нечеловеческих усилий?
- Правила должны помогать. Выгода от следования правилам должна превышать затраты на их соблюдение.
То есть, в идеале, правила должны быть идеальными. Про них все знают, они настолько просты, что их понимает сходу каждый идиот, следовать им ничего не стоит, а если следовать - то будет сразу ощутимая, видимая не микроскопом польза.
Да, забыл сказать - в идеале было бы хорошо, если бы новый сотрудник только нанятый на работу про них сразу знал. Ну, хотя бы, частично.
Ну так как бы не бывает, ну? - скажете вы. И тут на сцену выходят Фреймворки. Та-да.
Фреймворки дают вам правила проектирования, соблюдение которых, предположительно должно вам помочь. Задача фреймворка - сделать этот процесс проще, приятнее, и понятнее.
За этим мы и используем фреймворки. Они, как правило, задают некий скелет приложения, или его части, или скорее, правила их построения. За это мы их любим. В отличии от библиотек - их мы испольузем чтобы получить какую-то полезную функциональность, и как раз очень не любим, когда они начинают лезть не в свое дело, и диктовать нам какие-либо условия на структуру приложения.
Ну, в жизни, конечно, все немного сложнее. Выбором одного фреймворка дело не заканчивается. Фремворк может касаться какого-то одного архитектурного аспекта - например, только делать ORM. Его одного мало, чтобы сделать архитектуру, то есть, накрыть правилами проектирования все приложение. И кроме того, фреймоворки далеко не одинаковы в причиняемом ими добре - некоторые из них деспотичны, решая за вас совершенно все, а какие-то напротив, достаточно либеральны в плане там разных свобод.
http://stackoverflow.com/questions/802050/what-is-opinionated-software
Софт бывает opinionated, и unopinionated. Эти термины не имеют отношения к тому, какое мнение относительно софтины сложилось в сообществе. Здесь речь идет о "мнении" кусочка софта о том, как вы должны делать разные вещи (ну то есть правила он вам ставит). Библиотека как правило unopinionated. А вот фреймворк, чтобы быть фреймворком, просто обязан иметь какое-то свое мнение.
Короче, все бы хорошо, только количество разных фреймворков для веб-разработки одностраничных приложений давно перевалило за сотню. И каждую неделю появляется новый. Что говорит нам об одном - не смотря ни на что, никто до сих пор тольком не понимает, как правильно их делать. И уж во всяком случае, в сообществе нет на этот счет какого-либо общего мнения.