CAPモデル

私が思うに、まずは分業体制の観点から、入力、内部状態遷移、出力は、完全に分離されなければならない。
また非同期処理について人間が(なるべく)意識せずに済むようにしなければならない。

分業体制を考えるにあたり、

(C)コンダクター

入力機能。(コントロール等による)イベントの制御を行う。DOMやバックエンドのウェブサーバーとの通信等で発生するイベントを制御する。非同期処理の競合を調整したりするのも役目になると思う。調整されたイベントを後述のアクターに通知する。

(A)アクター

状態遷移の具体的な処理を行う。「状態(オブジェクト )」じゃなくて「状態遷移(処理)」。通知されたイベントと自分の状態(これはオブジェクト、てかプロパティか？)に基づく処理を行う。一般的なプログラムのイメージ。必要に応じて連動する別物ユニットに処理を依頼することになるが、これはコンダクターを介して行う。

(P)パフォーマー

出力機能。ビューの生成や表示を行う。HTML+CSSのイメージ。フレームワーク的には、アクターからの(コンダクター経由での)要請により、DOMツリーの生成、変更、削除を行う。ScssなりCSSを動的に制御できるのならそれも行う(要調査)

ってあたりをたたき台にして考えてみようと思う。
「MVC」じゃ無くて「CAP」ね。