[B~Vladi]

с MVC пришли к консенсусу

и по поводу событий тоже сходимся во мнениях

Вам нужно работать в одной команде.

Давайте ещё немного поговорим
Начну с описания того, что у нас есть, а потом уже решим что с этим делать. А есть у нас тупо:
1. HTML в связке с CSS.
2. JS-код. Все-таки мы пишем приложение.

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

Так, есть куча функционала в ТЗ. Если я все это дело раскидаю на отдельные логические составляющие, мне будет проще ориентироваться по всему проекту, а значит и поддерживать его. Сначала я опишу каждую составляющую более абстрактно, без привязке к отображению или к чему либо ещё, на какой-нибудь тестовой страничке. В такой среде код сам будет писаться как самостоятельный модуль. Аха, мы получили первый модуль. Получили второй. Третий. Внутри у них четко определённый функционал, раскиданный по нужным полочкам. О внутреннем устройстве вскоре можно будет забыть, но сначала нужно определить способ воздействия на внешний мир. API может вытащить наружу? Нет, связывать модули мы не будем. Может медиатор? Может. Наблюдатель? Тоже вариант не плохой.

А может нам объявить модули как модели, разметку как вид и реализовать для всего этого контроллер, превратив функционал всего проекта в одну классическую MVC-архитектуру? Хм... Это бы решило проблему с взаимодействием модулей... Но как? О, точно, у нас для этих целей уже давно придуман патерн Observer. Хорошо, он поможет нам реализовать синхронное взаимодействие контроллер <-> модель. Так. А что там у нас с видами? Задача контроллера - обновлять виды при изменениях состояний моделей. Прикроем-ка мы разметку классом вида и упростим общение с контроллером посредством, например, патерна Команда или того же API. Хм. В таком случае контроллер должен знать от кого в какой вид что посылать и поэтому может разрастись - моделей/видов-то много. Что-то больно тяжелый микс патернов получается, но вполне рабочий. Надо реализовать.

Что мы ещё можем придумать? А можем сделать все намного проще, как я уже намекал выше... Есть наша куча модулей... Реализуем общение между ними при помощи медиатора или наблюдателя, а о разметке забудем навсегда. Тогда, для качественной разработки модулей необходимо разделять их внутреннее устройство на составляющие, например на M, V и C. Решение рабочее, будем реализовывать.

Что получили в итоге. Самое интересное для нас - это модули. Мозг и логика всего приложения. Каждый кусок этого мозга влияет на все приложение в целом, а значит должно эффективно решать свои задачи. В первой реализации мы получили чистый функционал в коде модулей, без примесей. Во втором варианте же каждый сам за себя - плевать на все приложение в целом. Но не будет ли чистота первого варианта испорчена реализациями остальных компонентов - C и V?

Вот это я и хочу проверить. Как что-то будет готовое - отпишу.