Давайте немного подумаем, что мы хотим получить.

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

Например, у нас есть JavaScript-приложение, отвечающее за онлайн-пекарню. Одно из интересных нам сообщений может быть таким: «Партия из 42 батонов готова к доставке».

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

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

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

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

Архитектура, которую я предлагаю вам

Архитектура, о которой мы говорим, представляет из себя комбинацию трех известных шаблонов проектирования: модуль, фасад и медиатор.

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

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

Рекомендуем почитать:
Книги по JavaScript на ozon.ru
Книги по JavaScript на books.ru
Книги по JavaScript на my-shop.ru