Паттерны для масштабируемых JavaScript-приложений

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

«Секрет создания больших приложений в том, чтобы никогда не создавать больших приложений. Разбейте ваши приложения на маленькие части, а затем собирайте из этих маленьких тестируемых фрагментов ваше большое приложение» Джастин Майер, автор «JavaScriptMVC»

«Чем сильнее компоненты связаны между собой, тем меньше возможностей для их повторного использования, тем сложнее вносить изменения, не получая при этом различных побочных эффектов в самых неожиданных местах» Ребекка Мёрфи, автор книги «Фундаментальные основы jQuery»

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

«Секрет создания больших приложений в том, чтобы никогда не создавать больших приложений. Разбейте ваши приложения на маленькие части, а затем собирайте из этих маленьких тестируемых фрагментов ваше большое приложение» Джастин Майер, автор «JavaScriptMVC»

«Секрет в том, чтобы признаться самому себе с самого начала, что вы понятия не имеете о том, как ваше приложение будет развиваться. Когда вы согласитесь с этим, вы начнете проектировать систему основываясь на защите. Вы определите ключевые области, в которых, вероятнее всего будут происходить изменения. Очень часто это не составляет труда, если потратить на это немного времени. К примеру, вы ожидаете, что любая часть приложения, которая взаимодействует с другой системой — это потенциальная мишень для изменений. И вы понимаете, что здесь вам понадобится абстракция».
Николас Закас, автор книги «Высокопроизводительный JavaScript

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

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

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

Меньше связанности: используйте паттерны «модуль», «фасад» и «медиатор». Модули общаются через медиатор, а фасад обеспечивает безопасность.